 My name is Shannon Kemp and I am the Executive Editor of Data Diversity. We would like to thank you for joining the latest installment of the Monthly Data Diversity Webinar Series, Real World Data Governance, with Bob Siner. Today, we'll be discussing a data governance framework for success. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A section in the bottom right-hand corner of your screen. Or, if you like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG Real World Data Governance. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and any additional information requested throughout the webinar. Now, let me introduce to you our speaker for today, Bob Siner. Bob is the President and Principal of KIK Consulting and Educational Services and the publisher of the Data Administration newsletter, Tdan.com. Bob has been 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 introduce the webinar. Hello and welcome. Thank you very much, Sharon. Thank you, like always. Thank you, everybody out there in Listener Land for taking the time out of their busy schedules to sit through the Real World Data Governance webinar series. I've been looking forward to this webinar for quite some time. It's a little different than some of the other webinars, although some of the material that you're going to see may be shown in a little bit different of a context in this webinar than in some recent webinars. But this is really the opportunity to talk about an entire framework for data governance success. So if you look out on the Internet, there's a lot of people talking about different frameworks for putting data governance programs in place. So I'm going to share with you, as Sharon had alluded to, I talk a lot about the non-invasive data governance. But I'm going to talk to you about a framework for data governance in general and then some more specific things about non-invasive data governance. And hopefully some of the things that I'll share with you will make quite well. And certainly we're looking for questions down in the lower right-hand corner of the screen or you can follow up with me after the webinar. But again, thank you very much for taking the time to participate in this webinar. I'll just to let you know real quickly the webinar next month. I'm also really excited about that one because I don't get to do this all that often but I have a special guest who's going to be joining me for that webinar, Scambler, who is a specialist and world-renowned about his opinions about agile this and agile that. We'll be here to discuss with me about agile data governance, truth be told, and that's taking place on March 20th. And then on April 17th, we've had some requests for, and how we write a job description for somebody who's going to be a data steward within an organization and what would that entail and what goes into it. So I'm looking forward to the next two. And ours is as well as the rest of the series. So check back often to DataVersity.net and you'll find the information about how to register for webinars. I wanted to talk real quickly about the abstract here for this webinar because it seemed really interesting to me. I'm kind of new to the Twitter space and Twitter sphere but I saw a whole bunch of people had tweeted this first paragraph and posted it to places as to what their thoughts were on what a data governance framework must entail. And so it says here data governance framework must include best practices, roles and responsibilities, planning for communications, and an action plan. So I'm going to talk about all of these things in this webinar so I know we've got an hour so I'll get started quickly but I'm going to address each of those things in particular and certainly we'll be taking questions about any of them and if I rough up your feathers or say something that is something that you either want further explanation of at the end of the webinar or you want to extend the conversation about that please let me know that as well but those are the four primary pieces that I'm going to talk about. Again, best practices, roles and responsibilities, a communications plan and an action plan. So for those of you that already have data governance programs you'll know that these four things for most organizations are pretty much the staples of what you need in order to get started with your program. So we're going to talk again about a non-invasive data governance framework and we're going to talk again specifically about those four things. Now as I typically do with a lot of the webinars is I got to start kind of at the beginning because I don't know how many of the people that are on the call have attended the webinars before and how many of you are new to this series. If you're new to this series welcome, I hope you'll return. I want to share with you my definitions of data governance because I think it kind of puts in context what I'm talking about here as what is necessary, what's the framework that's necessary in order to achieve the things that we're setting out for ourselves in the definitions. So the definition that I use and if you've seen it before you can almost probably say it with me that it's the execution and enforcement of authority or the management of data and data-related assets. And I've talked about it before. I've said that this is something that is worded kind of strongly but in a lot of organizations it needs to be worded strongly. At the end of the day what we are really trying to accomplish is that execution and enforcement of authority over the management of decisions and through stewardship we're looking to formalize accountability for the management of data. The webinar that was really well received last month on data stewards and data stewardship, you know, talked about how anybody in the organization could be considered a steward of the data. So what we're really going to focus on is formalizing the accountability of these individuals and letting them know what role they play and what impact they have on the data across the organization whether they define the data or produce the data or use the data. And then I'd also really quickly share with you a definite of non-invasive data governance and it's in the practice of applying that a formal accountability and behavior through the non-invasive framework of roles and responsibilities which I'm going to talk about today. And we're going to apply governance to existing processes and to new processes and we're going to make certain that the data is compliant, that it is secure, that it is private, and that it's protected the way that we need to. So really non-invasive again describes how governance is applied rather than, you know, taking a 2x4 and smacking people in the head and telling them that they are a steward and their job is going to change this way or that way maybe what we really need to do is embrace what it is they presently do and understand where they have a relationship to the data and again formalize that accountability for the data. So again I thought I'd start with a quick definition. There's lots of definitions out there. I'd say every consulting company and every organization that focuses on data governance has their definition. Again I'd like to have mine have a little bit more kick to it. So it's something that will make people sit forward in their chairs and ask questions about well what the heck do you mean about executing and enforcing authority over the management of data and how the heck can we do this in a non-invasive way? So hopefully answer some of your questions regarding that if you have questions regarding the non-invasive approach. So again the framework that we're talking about here concerns those four things. Concerns themselves with best practice, all the model roles and responsibilities which I'm going to spend significant time on and again dissecting the model that I use quite often to describe the operational, tactical, strategic and executive level and supporting roles for a data governance program. We'll talk about the importance of the communication plan and as I do often I share templates and tools. If you're interested in seeing copies of these or receiving copies of them, make sure that we attach them to the email that Shannon talked about so everybody can get copies or larger versions of these templates and tools I'm going to share. I'm going to share with you a communication plan and share with you some action plans as well. So let's get right to it. First thing that we want to talk about today is best practice. A lot of organizations and a lot of organizations that I've spoken to recently have told me that one of the things that they want to do right out of the gate is some type of a critical analysis or a best practice assessment. So in order to do that type of a best practice assessment or critical analysis, we need to start by defining data governance best practice is and what some of the best practices are and what I've done here in the next couple of slides is I'm sharing with you some examples of some best practices that were actually taken from client information and they've been kind of scrubbed a little bit so it doesn't have any specific client information in them, but at least you'll see what some organizations are using as their basis of comparison as to say where are we in comparison to the best practices that we've defined. So in the organizations that have successfully implemented governance, typically start by defining a limited series of best practices, you know, they'll ask me how many best practices should we have and in my case, it really depends on your organization. But sometimes I find that somewhere in the area of four to six best practices for an organization will suffice. It will help you to make your case for where you need to start taking action and what those actions should actually be. So once the best practices are defined, organizations do this gap risk assessment to identify where they are in comparison to their best practices, they identify the risks that are associated with that gap between where they are and where they intend to be when it comes to the best practice. So yes, best practice critical analysis or assessment should provide these types of things. So not about best practice, typically what I say is there's really two criteria to determine if something is really best practice for data governance. So there are two criteria on the screen in front of you now. So the question is, is the statement of best practice practical and doable and will it add value for the organization? And if the answer is no, it's not practical or no, it's not doable or no, it's not going to add value, actually any of those, it's probably not a good idea to use that as your best practice. So the other question that I use or the other criteria that I use to determine whether or not something is best practice is, will our program, will our data governance program actually be at risk if we don't achieve what we've set out for ourselves as being best practice? So keep both of those two things in mind. Keep it practical, doable, and will it add value, and then if your program is going to be at risk, if the best practice is not achieved, and let's use those criteria to look at a couple different examples of sample best practice for organizations. So the first one that is listed on the screen here and actually the three of them kind of can be grouped together actually into one best practice. The first one is found in the majority of the organizations that I've worked with. And so the best practice that they define is that in order for governance to be successful, there will need to be a high level of senior management that supports sponsorship and understanding of the activities of data governance and the data governance team. So let's think about that for a second. If it's not practical and doable in your organization, it's not going to add value to convince your senior management that data governance is appropriate for your organization. Don't use this as a best practice. Also, we look at it from the other criteria. And typically in organizations, if they do not achieve a certain level, a high level of senior management supports sponsorship, and I usually stress the word understanding here because they need to understand what governance is about, the approach that you're taking to it. Without that, your program is going to be at risk. At some point in time, somebody is going to be asked to do something or get involved or attend meetings. And if they don't support sponsor and understand it, they're going to reorder these people's priorities. So we want to make certain that senior management is not only good in supporting and sponsoring what we're doing, but they have a thorough understanding of the approach that we're going to take, what it's going to mean to the organization, what it's going to cost, how long it's going to take, what type of return they're going to get. We need to provide that information to senior management. So again, that first bullet point there in order for your governance to be successful, best practice very similar to that is used in a lot of organizations when they're starting to put governance together. And one of the other things that I'm going to share with Shannon to share in the email that she sends out is a list of best practices. And a list of best practices that I've accumulated from a ton of clients over the years and I've kind of narrowed them down and removed duplicates just to give you an idea as to what would be best practice for a lot of organizations when it comes to data governance. So again, the first component putting together a data governance framework will be to do the assessment to understand where you are in comparison to where you want to be. And the way to do that is to define the best practice and then do that critical analysis. I want to share with you some more real quick examples of best practice in here or some sample best practices that came from a healthcare company. And you'll notice the first bullet point is almost virtually the same as the one that I just shared with you on the previous slide. For data governance to be successful, there will be a high level of data management support and understanding of the activities of the data governance team, the roles defined in the operating model, of which we're going to talk about next, and the specific examples of where data governance will add value. So again, it's just a often used best practice from organizations. And if in the course of the assessment or of the critical analysis, we identify that, well, maybe our senior management isn't giving us the support or sponsorship. Or maybe it's hard, but they don't really understand what it is that we're doing and we need to take steps in order to narrow that gap or to eliminate that gap. So again, it's a best practice in a lot of organizations that make sense that we get senior management on the same page as us. And the differences are that we're going to be at risk if we are not able to do that. Now, as I shared with you in other webinars, that oftentimes it's better for us to get the business people in our organization to tell you where governance is going to add value. And so when you're going, instead of us selling the virtues and the value of governance, if we can get business people to speak up about what they can't do because the data is not there for them in order to do these types of things, then we can take that as our case to our senior management and say, look, it's not us. We're not the ones selling the virtues of governance. It's the business people that are telling us that they can't do this and they can't do that because the data is not the way that the data needs to be in order for them to successfully do some of the other things that they're setting up to accomplish. Another practice from this healthcare company is select staff must be allocated, must be committed or allocated to the definition, development, and execution of the program on a continual basis. I've shared this before as well where I've had executive management from organizations to ask me, how many stewards are we going to need and how long are we going to need them for? Again, depending on my relationship to the person asking the question, my question to them would be, well, how long do we want to have quality data for? How long do we want to have secure data for? And if there's, well, we always want to have our data be high quality and we always want it to be classified and secured. Well, then the fact is the question of how long do we need them for really becomes a non-question because we want them as long as we want to have high quality data and high value data in the organization. And the truth is, are we going to be at risk if we don't have people in an organization that are committed or at least have some of their time allocated to put a governance program in place? And the answer to that is yes. Just ask any organization that has associated some resources to data governance and then taken those resources away. And then the program falls apart because, again, there's nobody there to facilitate the programs. Again, oftentimes organizations use that as a best practice within their organization. Data governance principles will be applied consistently. That's another example of best practice. The goal of expectations and measurements of success will be well-defined and communicated. Data governance should be considered an ongoing program rather than a one-time project. Again, these are all just examples of best practices from organizations. So normally, no matter where you are with your program, it will take several words to do this type of critical analysis. If you haven't defined your best practices for governance in your organization, perhaps it's something that you may want to do and then identify where in the current environment of data governance in your organization are you achieving the best practice? And either or not, what are the steps that we need to take in order to achieve best practice? Again, it becomes a very important first component of the data governance framework for success is to define best practices and then to go about doing that assessment of where we are in comparison to the best practices and then actually creating an actionable plan to come from doing that type of critical analysis as well. To pick up best practice for a little bit here now, what I want to jump into is the second of the primary components developing a data governance framework for success. That second component, the one that a lot of people think is being extremely valuable and extremely important. And as I show you templates and models, as I move forward with the rest of the webinar, you're going to see this is the backbone of the types of things that you're going to be doing within your organization. So I want to talk about this framework here and I want to dissect it even, send it in a good minute time, at least in this hour here, kind of walking through the different levels and trying to help people to understand that there's an operational level, a tactical level, a strategic and an executive level. To be honest with you, the first impression that people tell me that they get from seeing this operating model of roles and responsibilities is it's extremely bureaucratic. It looks like it's extremely complex and I really want to tell people that it really doesn't have to be viewed that way in order to help people to understand that it doesn't need to be viewed as being bureaucratic. That's why I've kind of pushed to the outside of this diagram the words that I'm circling here. We've got a data governance team and it already exists or at least we know that we need to have somebody who's allocating time like that best practices that we just talked about stated. We know that we've got IT and project management and we've got compliance people so they already exist. We know that we've got people within our organization that are defining producing data as part of their everyday job and some of the operational folks and they exist. The senior level within an organization we don't have to redefine what the senior level is for our organization. It already exists. So if we take away all the things and that's one of the things I should add to this graphic next time is remove everything from the picture that it already says exists in your organization and maybe it doesn't exist to the level that I've stated here in this webinar but if I removed all that you can see that we really need to focus again on that tactical level and on that strategic level and a bunch of things to talk about in regards to this picture. I could promise them the whole webinar talking just from this picture but this operational level is the largest space in the pyramid and therefore a lot of organizations is what I've found is they like to push as much of the decision-making down as low in the organization as possible. So if it's a business unit specific request we're going to push it down to the organization and have that decision be made in the operational base of the operating model that I'm showing you here. When the issues start to cross business units or cross different lines of businesses in the organization there's an escalation area here along the right-hand side of the pyramid that we escalate from the operational level to the tactical level and that's where we start to identify who in the organization has responsibility for a specific domain or specific area of data across the organization and who is breaking the ties and who are making those decisions. I've just said repeatedly in the webinars that that tactical level is the difficult hurdle to get over when you're putting into governance programming the place. And so I'm going to talk in a lot of detail about the data domain stewards as I've called them and the data steward coordinators and I'm also going to spend some time talking about the data governance council. So oftentimes there may be a council in your organization that you can take advantage of and you may call them your data governance council to start or it may be something that you start bringing new for your program. But where are you going to leverage what already exists in the organization or we're going to create something new called the data governance council and we're going to need to identify who in the organization these domain stewards are or we need to identify them and recognize them for being these domain stewards. And I'm going to talk more about each of these different roles within this pyramid. As I stated the bottom level of the pyramid since we push most of the decisions down to that level that's why it's larger in space. If you look at the tactical level it's smaller in space. If you look at the council it's even smaller in space that is consumed within that pyramid. And when we get to the executive level there's no space within that power that's sticking out of the operating model because we don't take decisions typically to the executive level of the organization. The block stops at the data governance council. So I've heard individuals tell me that if we take 5% or less of our decisions to the data governance council that's a figure that we should be shooting for. In other organizations it's been 10% there's been some that's been more than that. But the fact is if we need to take every issue to the strategic level of our operating model of roles and responsibilities within our framework for governance then there's a serious doubt shortcoming to the tactical level. So we're going to go through each of these in detail and just spend a couple of minutes at least on each of these and sharing with you where they play a role and framework for success for data governance. So there's another diagram on this page that I've shared before and I need to move pretty quickly here because time is going pretty quickly but this is the common data matrix. And the idea of the common data matrix is to cross-reference the data of the organization to the party organization that used that data and where they're finding that data in order to use that data. So there's several pieces to this common data matrix and again this is one of the matrices that I'll send to Shannon to send out with the email within the next two days. But the common data matrix seems to be one of the most utilized tools of all the templates that I'm going to share with you today. Because it's a way of cross-referencing the data we have in the organization with some kinds of data and what systems they reside in and the organization has plans on that data. Who's defining this data? Who's producing it? Who's using it? And if we subtract the approach that anybody who defines produces or uses data as part of the job has a certain level of accountability for how we define producing used data then these individuals become extremely important when we're putting together a program. So just real quickly here the components of putting together a common data matrix is first let's define a line across the top of this matrix again just a two-dimensional matrix. Let's define our information technology area all the corporate units all the business units all the admin units and each of those units may be bringing in the sub subsections of those same units and so they're all depicted on this diagram. In fact, so again if you look across the top that is really the layout of the organization in a two-dimensional spreadsheet here. Again this isn't necessarily the best place to keep this information but when you're going to share it with somebody in your organization they can get it. They can see it in one picture the reason why we have problems when we come to a specific type of data is because there's multiple people in multiple parts of the organization that are using that data in multiple places and have different definitions depending on the use depending on the understanding of that data. So this diagram again provides some of that assistance in that communications to people as to why is our data the way that data is and why do we need to record this information well the answer to why we need to record it is because we need to formalize the people in this current data matrix accountability for what they do with the data that they define, produce and use. So across the top it's organization across down the left-hand side the question I get asked about a lot is how do we define what our domains of data are and can we define our domains and then redefine them and re-redefine them if we need to and do we break it down into subdomains or do we get as granular as data elements? I get these questions all the time and the truth is it really depends on your organization. I would ask for virtually everybody that's on this call if you spent maybe five minutes or less jotting down what are the different subject areas of data that your organization is concerned with and you'd have at least a starter list of what domains of data need to be managed within your organization. Now the truth is that you can't manage you can't govern to all of your domains of data at one time. The idea is that we need to really do this incrementally and maybe do it domain by domain or even system by system in order to incrementally expand data governance across the organization. The last component here is that intersection and that's where the inventory comes into play. This is where we go out and we identify who it is in the organization that defines, produces and uses this type of data here as you can see from the highlighting in the specific system we can now see across the organization who is defining, producing and using that data in that system. It doesn't really cost you a whole lot to put together a common data matrix. It answers a lot of questions for people within your organization and when they want to know why you're having problems or why you haven't seen your management ask a question, a key performance indicator type question they get different answers depending on who they ask. Well, these people are using different data across the organization and the idea is that we need to be able to lay it out and we need to be able to provide governance across the different parts of the organization and how can we do that if we don't even know who's defining, producing and using what different data across the organization. So as I stated before, the common data matrix here is one of the most used tools, most effective tools for organizations that I've worked with. Now the beauty of those last two slides, the common data matrix and the pyramid diagram are the color coordinated. So you can see where we've got the data governance council and the pyramid diagram. We've got somebody representing each of the different parts of the organization. We're at the tactical level. We've got people who are looking at the data across the enterprise rather than a business unit by business unit basis. We've got those people identified over here. So again, the pyramid diagram and the common data matrix are color coordinated. And you're going to see with some of the additional slides that I'm going to share a little bit later on here that we can provide consistency in our communications across our organization if we can do something as simple as just color coordinating how we're representing some of this stuff to people across the organization. So what I want to do is I want to dissect each of these levels first and I'm going to do this relatively quickly. Please let me know if you have additional questions about these things. But I'm going to run out of time here real quickly. Let's talk about the operational data stewards, the lowest part, or should I say the bottom part of the pyramid. Also, those people that we've identified in our common data matrix to cross-reference the data and the parts of the organization that they come from. So the people that define the data that will be used by the organization, they produce the data, some organizations have gone as far as being that granular and how they define their stewards where they have definers, producers, and users. Some organizations have just kept it more at a level of operational data stewards rather than getting that specific about who's defining the data and who's producing it and who's using it across the organization. So the general responsibilities about the operational data stewards I really want you to focus on the last two bullets here. Because these folks that are out there in the field and out there working in the different business units of your organization, if they communicate new or changed business requirements to impacting individuals, or they can communicate concerns, issues, and problems that they have with the data, that's one of their core jobs. And it's really nothing above what they're presently doing within the organization. In fact, what is the role of the operational data steward? Well, this is not a typo what you're seeing on the screen in front of you. So we're going to type the same line twice. What is the responsibility of the operational data steward and is the responsibility for them to do what is expected of them in their job while being formally held accountable for how they do it, at least when it comes to data. So the question really here becomes what we're going to repeat that twice, because it's really worth repeating that these people within the organization who define, produce, and use data as part of their job, we need to know who they are, thus we need to record it in the common data matrix, and we need to be able to communicate with these folks individually or as a group. We need to know who they are so that when there's a change to a business role or there's a change to a compliance rule or there's something that's changed about the data, we know who the appropriate people are in the organization that we need to communicate with. So part of the webinar last month was the rules for becoming a data steward, as I said, virtually anybody can be a data steward. Being a steward really describes a relationship to the data. Stewards aren't hired. Stewards don't necessarily have to have the titles of data steward. I don't want to reiterate everything that I talked about in last month's webinar, but if you get a chance, go out and look at that webinar and see how I talk about each of these different items and the rules for becoming that operational data steward within an organization. So you may agree with all of those rules, you may agree with none of them. You know, one of the things that's been said to me when I talk about these rules for becoming a data steward is basically that it's a do-nothing approach. If everybody's a data steward, then maybe it's a data steward. Well, I don't agree with that statement. I think that it's more likely to look at it. It's a do-everything approach because we're going to identify across the organization who the people are that we need to hold accountable. So rather than it being a do-nothing approach, really following these rules for identifying who your operational data steward is more of a do-everything approach than a do-nothing approach. So what about the data domain stewards? Now we're working our way up through the operating model and these are people that are responsible for enterprise management of a domain or a subject area of data. You may call them enterprise data stewards. You may call them subject matter experts. You may call them what it is that their title is. You know, people in organizations what I found is that within the financial area, the financial domain in an organization that oftentimes the controller is the person that is the domain steward. The registrar for student data within a university, these are people that just by the mere fact of their position within the organization that they have responsibility for looking at the enterprise view of the data. A lot can be said about the data domain stewards and if you want to have an additional conversation with me about that, please feel free to reach out to me, but the data domain steward almost becomes the most critical aspect of putting together a successful data governance program where we can start looking at data as a cross business unit asset rather than a siloed business unit by business unit asset. So these folks have the responsibility for escalating well documented issues for making sure that the rules are being defined and that they're communicating for working in teams to solve problems specific to their domain of data. Some of these people may already exist in your organization and in some organizations that becomes one of the biggest hurdles is let's identify who is going to be the domain steward for a specific subject area of data across the organization. The data steward coordinator also exists in that tactical level within the pyramid. And again the pyramid is again just the second component to the framework for success of a data governance program. But these people act as the point person for communication between the people that are in the domain steward role, the data governance team, and all those folks out in the organization who are operational data stewards. So what I've done here is I've defined what are the responsibilities of the data steward coordinator. Well I'll honest with you, in the organizations that I've worked with if there's one role out of that whole pyramid that people try to eliminate first, it's the role of the data steward coordinator. But the fact is that we need to have people that we know within each of the business units of the organization as you can see in the common data matrix somebody who can help to coordinate the activities of the stewards or at least communicate effectively to the data stewards within that part of the organization. So one of the things that I see happening often in organizations are the domain stewards communicate with the steward coordinators who then communicate with everybody in their part of the organization. So the data steward coordinator plays an important role, somewhat even say a pivotal role in the success or failure of a data governance program. They can fill out the information on the common data matrix as well because there is some time that it takes to complete that and it's always a work in progress. So you're going to have a final version of your common data matrix and as people move throughout the organization where they exist in the common data matrix is going to change. Their accountability, because the data that they touch is going to change. So we can have a place to be able to record that information and again, that place is the common data matrix. How about the data governance council for me? A lot of organizations have talked about having a data governance council having a kind of a strategic board within the organization, a committee or a board or a council, whatever makes sense to call it within your organization. But the domain stewards don't have the ability to be able to make a decision or it needs to be escalated above the domain steward for approval at the strategic level of the organization. That is when we have the data governance council. The data governance council serves multiple purposes. I'm going to share several of them with you here. But we need somebody to break the tie. We need somebody to be able to make the tough, difficult decision when a difficult decision needs to be made. So why do we need a council? We need coordination, cooperation, communication, comprehensive risk management, consistency across divisions, across parts of the organization. And that is typically what the makeup of a data governance council is. There's representation from the different parts of the organization. So hopefully those of you that have councils or committees or whatever you call them, boards within your organization, you're putting your heads up and down and saying, yeah, that's exactly what a council does. So it's important to understand that we need this council, not only to communicate to and to get our senior management to understand what we're doing, how we're doing it, how we're being successful, but we're also there to break ties and to make decisions when difficult decisions need to be made. So what a council do, they become educated in governance, they approve things that need to be approved, things like policy or your role framework or your methods or your priorities. And one of their responsibilities is again to push some of that information down into their specific part of the organization. So if your senior most management and you're part of the organization does not support sponsor or at least understand what it is that governance is all about, it's going to be your program at risk. And those individuals that are going to be the ones that sit on the council that are going to be in the senior management or close to their senior management to help them to be able to understand what governance is, what they're doing for the organization, and so on. They make decisions at a strategic level in a timely manner, they meet regularly, they identify and approve pivotal roles, and they advise a council owner on the priorities that the governance program should set within the organization. So again, the council becomes a very important role in the framework for success of a data governance program. You get the question often, how much time is required of these individuals? Well, typically I would suggest that they attend meetings, they have to be sitting in 90 minutes a month on data governance. Anybody that tells you that they need more, if you're going to be able to go to people at this level and ask for 25% of their time, it's not going to happen in most organizations. So we've got to be very careful as to how we use their time in the meetings and how we use them to break ties and make decisions that can't be made at the tactical level of the organization. If they have the time available to read, review, comment, and approve documents, that could be another 60 to 90 minutes a month. So we're not really asking for a ton of their time, except not asking for them to understand what it is we're doing with governance and the role that they play. So when I said 5% to 10% of the data issues get escalated to that level, if a higher number gets escalated to your data governance council, it indicates some level of deficiency in the tactical level within your organization. So again, you just want to wrap up the roles and responsibilities section before we get on to the communication plan and the action plan. The responsibilities of the data governance program team, and again, we even had a best practice relationship to having somebody or somebody that has the allocated time to work on data governance, but they oversee the enterprise program, they architect the solution, they administer the program, they provide updates to the council, and so on and so forth. A lot of folks that are on the call, if you have responsibility for putting your governance program into place in your organization, they either be an entire data governance program team, which I've seen in a lot of organizations, or you may be a member of a data governance program team, and without a data governance program team and without somebody that has the responsibility for moving this forward in their organization, your program becomes at risk. So they develop and deliver educational materials, provide quality assurance, all these things. Again, I don't want to read through each and every one of them but please go back and look at the slides. They're asking me for additional information if you're more interested in wanting to know what does a data governance program team do. And then there's IT, and they're also in the support areas. Now, the interesting thing about IT is that we can't do the governance without them. In what we do, I think we're making a big mistake because there's a lot of people in IT that have a lot of knowledge about the data either from a system perspective or just from a strictly data perspective, the data modelers, the data movement folks, we need to identify who they are and we need to take advantage of their knowledge when we are solving data-oriented issues. Now, the reason why you see three columns or actually four columns in the common data matrix slide is that in a lot of organizations they have kind of these, what do you call them, skeleton or shadow IT departments that are specific to each of the different business areas. So, you need to take advantage of the knowledge that the folks have in IT, whether it's in a court IT function or whether it's in an IT function that is specific to a specific business unit within your organization. And what do you do with those folks or what are their responsibilities? You know, they focus on consistent protection and classification of the data, they're responsible for technical data handling, all of these things, securing the IT infrastructure, they're all the jobs of IT on a regular basis. So, what we need to do is work with them. We need to partner with them in order to put governance in place. Now, I've heard some people say that data governance cannot be successful if it starts in an IT area. You won't just say that because I know a lot of organizations where data governance is basically facilitated out of an information technology part of the organization. The thing is, if IT is doing it for IT's sakes and there's no business involvement, they're going to put yourself at risk. If IT is working as a partner, again, a partner with these people in risk and compliance or the people in project management, then there's much higher likelihood of us being successful is if we can partner with those individuals across the organization. It's not strictly an IT function, certainly. It's certainly strictly not just a business function either. We need to take into consideration everything that information technology and the people in information technology, those data subject matter experts and systems subject matter know and understand about the data. We need to take advantage of that rather than doing it as strictly a business function or strictly as an IT function within an organization. Now, I'd be up that second component of the framework of the operating model of roles and responsibilities. I hope that some of that information makes sense to you. Hopefully, there have been some questions regarding that, but it's really important the role and responsibilities that you define for your governance program become, again, the backbone of a lot of the things that we're going to try to do as we start to move the function of data governance into the business areas and as we incrementally expand across the organizations. So as we recognize organizations who define person and use data, and not virtually anybody, we know that we need to communicate with these people effectively. People that have had successful data governance programs always seem to talk about their ability to be able to communicate with people in the organization. And after this past summer working with one of my clients in New York, we thought we were actually working with people communications down into three basic levels. There's orientation communication and there's onboarding communication to get people up and running as to what their role is in the organization, and there's ongoing communications. I think it would be really helpful if we could kind of put that into a picture and we could show to somebody in the organization, well, first of all, communications is very important, so let me share with you a couple of diagrams here. This is one that I've used. In fact, I used it a long time ago and I still like to show it because it's, again, a pretty simplified view of working at things. Whereas here are the items on the hand side that we know that we need to communicate to the organization. Here are the different parts of the organization, according to the operating model that we just talked about, that pyramid diagram. And if we can identify whether or not we're going to communicate this information to this audience, then we can fill in this block here and we can determine whether or not we even need to communicate about this item to the audience. You can start filling in this diagram with information about what needs to be communicated. How are we going to communicate it? Are we going to do it in meetings? Are we going to do it in brag lunches? Are we going to do it through emails? What's the format we're going to communicate about something like this? These are the things that need to be communicated and these are the people that need to be communicated to. It really puts your arms around how much communication work is going to be necessary within your organization. And another thing that I wanted to share with you, and I'm finding it to be a fact within a lot of organizations, is that there's somebody from the communications team for the organization that becomes a part of the governance team. They recognize that communications is such an important aspect of a successful framework for the governance. So adding somebody from your communications area, or at least having them at your disposal to use them whenever you need, that makes a whole lot of sense in a lot of organizations. The idea is that we put together a communication plan and that we have somebody who has the responsibility for executing on that communication plan. One more picture that I wanted to share with you around the communications plan. Here's one that's kind of color coordinated. I'm not sure that these colors really well match up with some of the colors on the other diagrams, but you can show them when we break it down into onboarding communications or ongoing communications. And one of the specific things that we need to communicate as part of onboarding or ongoing communication, who doesn't need to be communicated with a client of mine created this picture, put it in their website, and if you click through any X's, you can see exactly what messages are going to be shared for this type of communication to that specific audience. When they expect to get some additional communication or communications about it, where they can go to attend meetings to talk about these types of things. Again, it's a little bit more colorful, but again, the idea of having the colors in this diagram is the idea of having the colors is that it syncs up with your common data matrix. It syncs up with your operating model and your roles and responsibilities. So again, there's a consistent message across your communications to people in your organization. And then the one last thing that I wanted to talk about in regards to a communication plan, and I've shared these in the past, but these are some specific messages that a lot of organizations use to share with their management. The first thing is we're already governing data, but we're doing it informally, inefficiently, and effectively. Now we govern data by putting a framework around it, by putting structure around it, and certainly by developing best practices and operating model communication plan and action plan. We can formalize how we govern data just by putting structure around what it is that we presently do. So we can improve in these areas. We don't have to spend a ton of money in order for governance to be successful. I've been known to state in the past that governance is as expensive and certainly people's time is money, and it'll tell you that over and over again. The fact is if we can demonstrate to them that we can help to make them more efficient and more effective, they're going to be very willing to participate and spend some of that time with us. So the first message is again, it's very important. We're already governing data. We can do it more efficiently. We can do it more effectively. We need to put a framework in place that involves all those things that we've talked about in the webinar here. We have the action plan and the last component of the framework for data governance success. I'm going to share with you something that I've shared in other webinars, but I'm going to go into a little bit of detail. I'm going to use some governance activity matrices or RAIDs charts or SDLC or methodology charts. One of my pet pieces that I have is that people refer to things as data governance processes. So in reality what we're really doing is we're doing processes. If you call them governance processes, then we're taking the risk that people are going to view these processes as being in the way, as being roadblocks to their success, as something that would thwart their creativity. When the fact is, no, we're applying governance processes rather than labeling everything as a governance process. So really it's just a matter of semantics, but when you're out there convincing people in your organization that if you call everything a governance process, they're going to think that the reason why you are following that process is because you have data governance. In reality what we're doing is we're applying governance to the processes. We're getting the right people involved at the right time for the right reason and all those things that I've talked about before in the data governance bill of rights. So, wow, there's nothing on this diagram. It's interesting. There's nothing before him, but the idea now is to cross-reference the steps of a specific process and I'll talk to this blank slide here for a minute. It's with the people in the organization across the top with the roles from your data governance program so we can define exactly who does what in each step of your methodology or your process. Here's an example. I'll share with you this example that you can see for a racy matrix in regards to six of the primary activities that are important to this one organization. So if you can see on this slide the repeatable actions, the things that they wanted to be able to do repeatedly within their organization was resolve information quality issues, identify and monitor risk, monitor improve quality of life cycle, all of these types of things, and they may be different processes for you, but what we did in creating this action plan was if you clicked on something like resolve information quality, then it comes a list of all the steps for that and the different roles across the top. So again, now we've got these two-dimensional activity matrix that says these are the steps that we're going to follow. These are the roles associated with governance and this one precisely tells us who do we get involved, when do they get involved and what exactly do they do. Some organizations have even added a column that says, well, what is the outcome of involving these people this way across the organization? And there's a couple of different ways you could use a diagram like this is you could put an R and A and a C and a I in each of the blocks to identify who's responsible, who's accountable, who needs to be consulted, who needs to be informed, or you could take another approach to it. You could put information like that's what specifically specifies what the person in this specific role does in this step of a specific process. We can state how many hours per week and how many people are required. Again, we can cut and shape this action plan, this action matrix in a way that makes sense to our organization and I'm just sharing with you a couple examples of those here today. So if any of these make sense, I'm going to include these in the templates that I'm going to share with Sharon to share with all of you and hopefully it will add value to you in your organization. Another example of action planning. These are all proactive. We're all building this in to processes within our organization. Here's steps to certify enterprise data warehouse data. Here's the different roles. Again, color coordinated to match up with our common data matrix or our operating model and we can identify who needs to be identified, who's accountable, who's consulted, who's supportive, who's informed. Again, it's a way of being able to sync up your message across all these different artifacts that you're using to demonstrate governance to your organization and exactly what it's going to entail as we're putting governance in place. So the proactive side, the reactive side, I'm just going to spend a minute on here on this real quickly. If we have a methodology that we follow to solve problems, we can do the same thing with the methodology. Here's the steps that follow to solve a problem. Here's the different roles that we have associated with our governance program and here is who's responsible, who's accountable, who's consulted, who's informed. Basically, it has a rule for following the specific process within your organization. So again, I kind of want to summarize here before we take some questions. The non-invasive data governance framework consists of those four things that we talked about today. It's the best practice of the operating model of roles and responsibilities, which is that pyramid diagram, the commissions plan, the action plan. If you can build those things, you're going to be well on your way to developing a successful data governance program. So that kind of itself is really your framework for a successful governance program is to have best practices, roles, responsibilities, a communication plan, and an action plan. If there's anything that I've missed here, please share that with me. I'd love to address it, but in a nutshell, that's what a framework for success for data governance is with organizations. Just a quick reminder, next month is the Agile Data Governance Webinar with Scott Ambler. The month after that is the Webinar on how to write a data stewardship or data steward job description. With that, I'd like to turn it back over to my friend Shannon and see if we have any questions for today. We have lots of questions. I just love how active everybody has been on the chat and everything today that's part of the culture that we just definitely want to nurture here at D-Diversity, sharing best practices. And some of the most popular questions, of course, are people asking if they can get a copy of the slides and the recording and of all the fantastic things that you have shown here in the presentation today. And I will be sending out a follow-up email to everyone by end of day Monday with all these links and information. And I will also include a link to all of your previous webinars so that everybody has that as well so they can go back and look at the data stewardship one, especially. So, at the top here, we have a lot of fantastic questions coming in. And please, if we don't have time to get to your question, Bob is great about answering these and we'll also get the answers to your questions. So keep them coming in the follow-up email. So the first question, it was not really a question as much as a statement. It just in some way, in my mind, there is no such thing as a best practice. A best practice is industry and organizational specific. It is not one size fits all. And so you continually stress best practices. So can you expand on that a little bit? Certainly. So best practice plays a role for a lot of organizations because if they don't identify what their target behavior is that they want to achieve, then they're kind of doing the readyfire aim approach, which is not really directing their activities anything specific. So if you're familiar with the book, Seven Habits of Highly Effective People by Stephen Curry, one of his effective habits is beginning with the end in mind. And so my suggestion is if you really want to be effective and you want to be successful, the implementation of your governance program, let's begin with the end in mind. Let's identify what is the target behavior, and then let's compare ourselves into that behavior so we set up our actions to follow that assessment. Now the thing is, there is not a one size fits all best practice. A best practice for one organization may not be a best practice for another organization. Or maybe it will be. I guess there's been a lot of consistency in best practices from organization to organization, but they're not ever worded exactly the same. So my suggestion is, yes, there's not one set of best practices. Yes, there's not necessarily an industry best practice, although some people may write it if there is, and there are definitely specific to the organization. I think the best practice is, yeah, I kept referring to it because I think it becomes a critical first component to the development of a successful data governance program. Another question, it is physical physics. A data governance program at rest stays at rest. A data governance program in motion stays in motion. Do you agree with that statement? I don't like that. I've never heard that before, but that's really good. It's like, what's that, the CEO of relativity? No, it's a, what am I saying? That's what I'm saying, series, right? Yeah, that's what that is, but if you have nobody doing it, nobody's going to get it done. So I agree wholeheartedly with that statement. If you don't have a council that engaged, nothing's going to get done. So if your program's at rest, it's going to stay at rest and somebody comes in and kind of takes it in the behind. But yeah, I agree with that statement. A program at rest stays at rest unless acted upon by an outside source. And then I think we have time for one more question here. So we can all agree that members of the Data Governance Council should be senior management. The question remains how senior or what level of management hierarchies should these people be? Highest level of the organization such as the senior level members or executive management members or senior management members? That's a great question. And again, I guess the best consulting answer I could give is it really, it depends. And so I'm not going to stop with that. I'm going to tell you what it depends on. Typically what I would find is that each of the departments or each of the divisions or each of the one of the corporate entities within an organization that they could be represented on a Data Governance Council. So the question then becomes at what level are they going to be represented? Are they going to be represented at the C level? Well, typically the C level is going to be the executive piece of that pyramid, the little tower that sticks out of the pyramid. Typically it's going to be somebody who, somebody at the C level of the organization from that part of the organization designates to resent their part of the business area on Data Governance Council. So if they're not high enough to be able to make tough decisions when they can't be made at the tax school level, then maybe they won't be the appropriate person to sit on the council. But then again, some organizations are a lot deeper than other organizations. Typically it is, again, somebody that can represent that part of the organization. It doesn't have to be a C level. It's typically at least a director if not a VP or an EVP or a lower level VP or somebody that can truly represent that part of the organization when it comes to the strategic level of your successful Data Governance project. Unfortunately, that's all we have time for today. But again, I will get Bob writes up the answers to the questions. I'll make sure and get you all the answers within the follow-up email that again will go out by end of day, Monday with links to the slides, the recording and everything else that Bob mentioned in the webinar today. So Bob, another great presentation. And again, thanks to everyone in the attendance today and for all your fantastic interaction. I just love it when we can connect people with each other and help everyone out in their programs. So Bob, thank you so much. Thank you, Sharon. Looking forward to the next one. Agreed. All right. Take care, everybody. Have a good day. Thanks for attending. Thank you.