 Hello and welcome. My name is Shannon Kemp and I am the Executive Editor for Data Diversity. We would like to thank you for joining the current 2015 installment of the Monthly Data Diversity Webinar Series, Real World Data Governance with Bob Siner. Today Bob will be discussing Data Governance Framework Components. 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. For questions, we will be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you like to tweet, we encourage you to share our 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 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 is 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 get today's webinar started. Hello and welcome. Thank you very much, Shannon. Thank you, everybody, for taking time out of your schedule to attend this webinar, whether it's morning, afternoon, evening, tonight, or you're listening on a recording of this. I really appreciate your taking your time to participate in this series. I really enjoyed doing it, and I'm glad to have you here. As Shannon said, my name is Bob Siner, and I'm going to be talking about Data Governance Framework Components today. And oftentimes I get a question. In fact, one of the questions that I get more often than any other question is, if we could really limit it down to just a handful of things that we need to focus on in order to be successful with our data governance programs, what would those things be? So I've seen frameworks that have had 20 items. I've seen frameworks that have had 10 items or 15 or somewhere in between there. But what I'm going to talk to you today about is four primary components of what I think are necessary and what a lot of the organizations that I've worked with think are necessary in order to put a successful data governance program in place. But before I get started, as I usually do, I want to share a couple pieces of information with you. One is the information about my book, Non-Invasive Data Governance, The Path of Least Resistance and Greatest Success. It was published in September, and it's available on Amazon through Technics Publications anywhere that you can find any of your best booksellers anywhere. So please take a look for the book if you get a chance. Second thing I wanted to point you to was kikconsulting.com, the website that has all the information you could ever want about non-invasive data governance. If you're missing something there, then please feel free to contact me. I'll be glad to fill you in on what I believe is a very successful and a very practical approach to data governance. And third but not least is the Data Diversity Event that I will be speaking at in June, the Data Governance and Information Quality Conference. And I'm going to be giving three presentations at that event. One is Getting Started with Data Governance. That's going to be a tutorial, Advanced Metadata Requirements for Governance. That's another tutorial. And then I'm going to talk about Applying Data Governance to Agile Projects. Also, just to let you know, the upcoming webinars in this series in May, one of the most popular webinars of the series that I've done, usually focus around tools and things that we can develop ourselves internally that don't cost us a lot of money, that will help us to put a successful governance program in place. And I'm going to share some of those in the session today. I'm going to go into much more detail next month, but some of those tools and templates will be shared during this webinar today as well. And in June, I'm going to talk about the subject that I think is controversial. I'm hearing from people that it's not as controversial as I thought. If you've followed me in my approach, I talk about the fact that everybody in your organization that has a relationship to the data is a steward of the data. And they have some formal accountability for how they define produced data, produce and use data across the organization. So that one is labeled everybody is a data steward, how to deal with it. I look forward to having you attend those webinars in the coming months as well. So the webinar that we're talking about today is Data Governance Framework Components. And I'm going to talk about those four primary components that I mentioned earlier. Well, first of all, in organizations, there are typically several basic components that really go into making up a good program. In the framework that I use, there are the four that I'm going to talk about today. And they are listed at the bottom of the slide that we are on right now. The first and foremost kind of outside of those four components is the one about gaining leadership and backing, or gaining your leadership's backing and understanding of what governance is, the fact that you're already governing data, how we can be very practical in the way that we put our governance programs in place. And then the four primary components I'm going to talk about are the best practices, talk about best practice analysis, leading to recommended actions, operating model of roles and responsibilities. As I've talked about before, roles and responsibilities lie at the core, lie at the heart of any successful data governance program. So I'm going to share with you a very simple, non-invasive operating model of roles and responsibilities. We'll talk about that to some level of detail. We'll talk about a building of communications plan because communications also seems to lie at the heart of successful data governance programs. I'm going to share with you a model that you can use perhaps to develop a communication plan that will help in your organization. And then last but not least, in this situation as well, we'll talk about the action plan and the roadmap for success. These are the four primary components that I believe very strongly in that if you have these, if you've done your due diligence and done a best practice critical analysis, and you've built an operating model of roles and responsibilities that fits into the culture of your organization, and that you communicate successfully and you have a plan for how you're going to put your governance program into place. If you have these four components, they're really going to take you a great way towards success in the development and the implementation of your data governance program. For those of you that have not heard these webinars before, I also want to start with the definitions that I use for data governance and that I use for data stewardship. I get a lot of pushback on the definition that I use for data governance because people tell me that it's worded too strongly. It makes them cringe almost. You know, when I talk about data governance being the execution and enforcement of authority over the management of data and data-related assets, people ask me why I need to use the words execution and enforcement of authority. Well, the truth is, no matter how you address data governance within your organization or information governance in your organization, the fact is at the end of the day, we need to be able to execute authority over the management of data. If a person is defining data, we need to make certain that they don't go out and define data for a 15th time or a 20th time or a 30th time, that they look to see what data is already there and they're held accountable for not defining data again and again. And again, if they produce data, people who produce data have that accountability for producing the data the way that the data needs to be produced. And certainly people who are using the data need to understand security rules, privacy rules, regulatory and compliance rules associated with the data. So when I talk about data governance being the execution and enforcement of authority, the truth is that there's a lot of people in the organization that have a level of a relationship to the data. We need to help them to understand their impact on the rest of the organization. And we need to execute and enforce the authority over getting these people to do the right things in the right ways and to help us to improve the value of data to our organization. The definition that I use for data stewardship is the formalization of accountability and this kind of goes back to how I talk about everybody being a data steward and I'm going to talk about that in a webinar coming up soon. People that have relationships to data, typically they're already stewards of data. They already have some level of accountability for what they do. We want to formalize that accountability. We don't want them to feel like we're hitting them over the head with a stick and telling them what to do, but we do want to make them understand that they're important and that they have some level of accountability depending on their relationship to the data. And if we can formalize that accountability, oftentimes that too goes a great distance into our organization as far as getting people to be accountable for the data, for governing the data so that we can execute and enforce that authority, which is again the definition that I use for data governance. I talk about non-invasive data governance a lot. I want to just share with you my definition of non-invasive data governance as well. So it's the practice of applying formal accountability and behavior through a non-invasive framework of roles and responsibilities, applying governance to existing processes or building processes new and then applying governance to those to make certain that the definition of production and usage of data assures those things. Regulatory compliance, security, privacy, protection, quality, all of those things. Non-invasive data governance really, it's telling us, it's really the way that governance is applied in our organizations and the goal is to be transparent, supportive, and collaborative. So with those as basic understandings, what I want to talk to you about today is the things that you see on the screen and in front of you right now. First, I'm going to talk a little bit about gaining leadership backing because we know it's very important that our senior management not only supports and sponsors what we do when it comes to data governance, but they understand the approach that we're taking and how we are going to hold people formally accountable and how we're going to execute and enforce authority without, again, hitting them over the head, making them feel afraid of what data governance is, thinking that data governance might be threatening to them or to their position. The idea is we want them to understand that we can be non-invasive in the approach. There are alternative approaches to what people have labeled as command and control around data governance. So the four components, again, are the best practices, the operating model of roles and responsibilities, a communication plan and an action plan. So it sounds like a lot to cover and the amount of time that we have left. Let me get to it right now. First thing that we want to talk about is how do we gain leadership backing in data governance. That's another question that I get a lot from organizations is that we understand that data is an asset that needs to be managed and we understand the importance of data as our lifeblood of our organization. And we want senior management not only to support and sponsor that, but to understand the approach that we're taking. So there's these five core messages that I suggest that we share with our management to help to gain their backing, to gain their support and their sponsorship and their understanding. And the first message right out of the gate is, you know what, we're already governing data. You know, oftentimes we're doing it informally, we're doing it inefficiently, we're doing it ineffectively, but there are already people in your organization. You might call them subject matters, experts or owners of the data, but we're already governing data. We have some things in place. We have some decision makers in place. We recognize that everybody in the organization that has a relationship to the data, it needs to be held formally accountable for that relationship. So if we go to management and we tell them that data governance is something that's brand new to us and that it's going to be expensive and it's going to be time consuming and it's going to be complex, that's what they're going to understand. That's what they're going to believe. If we go to them with a little bit different message of saying, you know what, we're already governing data, but we can do it better. We can improve the way that we're doing it by formalizing the accountability around the management of data. So that's the second message is we can formalize how we govern data by putting structure around what we're presently doing and some of the tools and templates and things that I'm going to share with you today will help you perhaps to formalize how you realize that you're already governing data in your organization. The third message is we can improve how we manage risk, how we secure the data. We can improve quality and provide quality assurance. We can improve coordination, cooperation, and communications around data if we just know who does what with data across the organization and we identify those people in the organization that have levels of responsibility as decision makers. And again, when I talk about the roles and responsibilities here in a couple of minutes, I'm going to talk about the needs for a strategic level of data governance counsel. I'm going to talk about a need for a tactical layer of the subject matter experts or the domain stewards as I've called them in the past. And I'll talk about again the formalization of the accountability at the operational level. If we formalize what people do, their behavior associated with the data, we can manage data risk and secure the data better. We can improve quality and certainly we can improve those 3C, the coordination, cooperation, and communications around the data. The fourth message out of these messages is one that some of the vendors may not agree with, but the truth is we don't have to spend a lot of money on data governance. What we need to do is we really need to spend some time on it. We need to give somebody some responsibility for it. So a lot of the tools that are on the market are excellent to enable your programs, but the fact is that by purchasing a tool and by implementing a tool, it doesn't give you a data governance program. We're really focusing on governing people's behavior, and we don't need to spend money. We just need to spend time on it and come up with an approach that's going to be workable given the culture of our organization. The last message for gaining leadership backing is we need structure. We need to put something in place in our organization that's going to be easy to communicate to people and help them to understand that, yes, they see themselves in this program in the way that it works. They see themselves as being a steward rather than us having to assign them to be a data steward. If you've heard my webinars in the past, that's one of my pet peeves. I hate the term assigning people to be data stewards. In fact, I started using the term identifying people as data stewards rather than assigning them because identifying people doesn't seem to come with as much baggage or as much weight. In fact, one of my clients said, we should use the term recognize. We're going to recognize people in the organization as being data stewards, and that is a positive connotation to it. They're recognized for the relationship that they have and the data. They're recognized for the fact that they will have an impact on the value of data and the quality of data within the organization. So that's really not one of the core components that I wanted to talk to you about in this webinar, but it's something that's very important to a lot of organizations as they're getting started in putting their programs in place. So the first core component that I want to talk about is best practices. In fact, the webinar that I did back in March of this year was focused on data governance best practices. So if you want more information that I'm going to talk about here, please go back and view the audio and the video of that webinar. That's available through Data Diversity as well. But there's a lot more detail about data governance and actually in that webinar, database administration best practices as well. So when I talk about best practices, typically I'm not talking about creating dozens of these things. I'm talking about finding some very core items that we need to define that will help us to assess where we are in our organization as far as our readiness and our ability to be able to govern data. So organizations that successfully implement these programs start by defining this limited series of best practices and they assess themselves against those best practices before they get started down the path of implementing their data governance program. And in fact, some organizations, some of your organizations may have data governance programs that are already in place. Oftentimes, if you don't have best practices defined as part of your program, you might want to look at some of these best practices and assess yourself against these best practices to make certain that you're heading down the best path possible. So once you've defined, again, a limited number of best practices, the first thing that we want to do is we want to identify those things within the organization that we're doing that already support these best practices. Again, the idea of being non-invasive is to not go around with the club and hit people over the head and change their titles and change what they're doing. The idea is to help them to improve what they're doing in terms of their relationship to the data. So organizations define these best practices and then they say, what are we doing that already supports it? Because that's not necessarily something we need to focus on. What we really need to focus on is what we're not doing. And so if we take the best practice and say, okay, here's the things that we're already doing that support it, but here are some opportunities for improvement, we want to focus on the opportunities for improvement. And then once we've done this assessment against the best practices, we want to define what is the gap between what we're presently doing and what is the risk associated with that gap. Again, the gap between what our present actions are and what we define in the best practices. And then once we've defined the gap and the risks associated with it, use that information to help us to develop the action plan. And the action plan is going to be the last component that I'm going to talk about today. So again, best practices is where a lot of organizations get started when they're putting their programs together. And what I wanted to do is share with you some criteria that I typically use to identify if something is best practice for our organization. So there's these two questions on the screen that I feel need to be answered yes in regards to the best practices that I'm going to share with you or the best practices that you define for your organization. First of all, practical, doable, and is it going to add value to the organization. If it's not practical and it's not doable and if it's not going to add value to your organization, my suggestion is you might not want to consider that as something that you define as being best practice around data governance for your organization. The other criteria, and just as important, is the fact that we should ask, will our program be at risk if we don't achieve the best practice? And again, I believe the answer to that question should be yes as well. And so I'm going to share with you a handful of best practices on the next slide, but just real quickly, I wanted to touch on a couple more key points around best practices that I haven't shared before. I've seen a lot of organizations or I've seen at least some organizations that have come to me with lists of dozens and dozens of best practices or best practices around database administration and best practices around data modeling and best practices around metadata management. The fact is that there's a lot of really good practices around these areas, but they may not be considered best practice the way that I'm using the term best practice in this discussion. Again, the best practices that I'm going to share here, they need to be practical and doable and they need to add value to the organization, but they also, if we don't achieve them, our program is going to be at risk. So make sure that we understand the difference between best practice and just practice in general. And you're going to notice that the best practices that I'm going to share with you here again on the next page are worded in the present tense. Let's talk about them as if they're taking place today and then let's assess ourselves against those things. So here are a handful of best practices that a lot of organizations that I work with share or use for their organizations. So the very first one is there's a high level of senior management support sponsorship and understanding of the processes, definition, activities of the data governance program. Is it practical and doable? And will it add value if we can get our senior management to not only give lip service to data governance and support and sponsor it but truly understand the approach that we're taking in getting people in the organization to be held formally accountable for what they do with the data. And in fact, I'd be lying to you if I said that the very first best practice on the list here is only used in 90% of the cases because it's actually used in more than 90% of the cases. And in fact, in a lot of the organizations that I've had the honor of working with, this is the very first best practice. If senior management does not support sponsor and understand what the heck it is doing around data governance, the chances are that we're going to be at risk and our program is going to fall upon hard times at some point in time. So senior management support sponsorship and understanding is that very first best practice that we need to assess our organization again. We may find that there are levels of support and sponsorship but that the understanding is lacking. So then when we develop our communication plan and our action plan, then we need to make certain that we're spending time making certain that our senior management understand what the heck it is that we're doing. The second best practice, and I could talk to each of these all day if I had the time, but I won't do that here. The second one is that resources are dedicated to the definition, development, execution, and sustainability of the program. Now again, the fact is that if we don't have people, well first of all, is it practical and doable that we have resources that are dedicated to this program? And dedicated doesn't need to be 100%. It could be 50%, recognizing that you're not going to get things done as quickly if you don't have people that are dedicated full-time to this. But we need to have somebody that has responsibility for the program. Is that practical and doable in our organization? And in most organizations, we'll say yes, that makes sense. It's the best practice that we have resources that are dedicated to this. Are we going to be at risk if we don't have resources dedicated to data governance? Is the program going to be at risk? Well, I would say for sure that you're going to be at risk if nobody has accountability for moving this forward. Data governance principles and the concept of stewardship are the backbone of making the actions and assurance of managing data consistent and habitual. We want to make certain that we define core concepts and core principles around governance and then around the stewardship of data. Is it practical and doable? Yes, we can do it. Are we going to be at risk if we don't have these things defined? Most organizations will tell you that they will be at risk if they don't have their core principles and their concepts of stewardship defined within the organization. Data governance being applied consistently and continuously, we can look at it the same way. Practical and doable, yes. Are we going to be at risk if we apply it inconsistently? Yes, we're going to be at risk. And the last one being goals, focus areas, roles, and responsibilities, measurements of success. I've seen a laundry list of items included in that last best practice. Is it practical and is it doable that we define goals, focus areas, roles, and responsibilities? Again, I would say yes. In most organizations, it's practical and it will add value to do that. Are we going to be at risk at some point if we don't do those things? And again, I believe that the answer to that is right. If you're interested in a series of best practices for different industries, I'll be glad to share those with you. Again, like I said, we could spend the whole time talking about data governance best practices because they really lie at the heart of the program and what I typically suggest would be the first thing that we would do when we get started putting a program together. The second core framework component of a data governance program is roles and responsibilities. And so I've shared this model before. For those of you that haven't seen it before, you may look at it and say, wow, it's very bureaucratic. There's a lot of different levels that we're talking about here. When I talk about operational and tactical and strategic and executive and then having supporting areas like the data governance team, it sounds like a lot, but the truth is in a lot of organizations, this is the way that they're already set up. They have people at the operational level, at the tactical level, at the strategic level, and at the executive level. And one of the things that I suggest with this component of the framework is that we don't try to plug our organization into this operating model of roles and responsibilities. Rather, I would suggest that we do exactly the opposite. We take a look and see, well, what do we have at the executive level? Do we already have a council or something that looks like a council at the strategic level that we can take advantage of? Do we already have people who are subject matter experts at the tactical layer? Do we already recognize that people who have a relationship to the data are stewards? Certainly some of these components may seem a little bit new. The data governance team is on the left. I call those the sidebar for this operating model. And then the data governance partners. In the past, I've talked about that as being IT, but it's actually regulatory and compliance, project management, information technology. All of those different parts of the organization, they're partners with the data governance team. We need to identify who they are and record who they are and help them to understand what role they play in data governance. Again, the first thing people see when they see this model is that there's all these different layers of roles and responsibilities. The fact is, it's really important, these things along the outside of the diagram, it says, we've already got somebody who has responsibilities for data governance, so that already exists in the data governance team. The data governance partners, we've already got regulatory compliance and project management. We've got IT, so they already exist as well. The executive management, the stewards at the operational level or at least the people at the operational level, they already exist. In fact, the suggestion that I have is that these areas in the middle of the diagram, trying to get my pen to work here, it's not working, the two layers, the layer in pink and the layer in yellow, are really the ones that we need to focus on when we're putting our governance program into place. The data governance council, which we'll talk about here in a minute, and the data domain stewards or the subject matter experts in the organization, we need to recognize who they are, we need to have a way of being able to record who they are, and in fact, if you've never seen this before, I find this to be one of the most powerful tools in implementing a data governance program. And I talk about the common data matrix as being, again, one of the first things that we should do in our organization in order to be successful around governance, we need to record who does what with data throughout the organization. So if you look at this organization, it's a two-dimensional grid. On the left-hand side, we have the different types of data, subject ant matters of data. We have what systems they reside in. We know who are the different business areas. We want to record in each of those squares who are the people in the business areas that are using this particular type of data in this specific system. Who will we reach out to if there's a change to that data or a change to a business rule associated with that subject matter of data? The common data matrix from my experience becomes a very valuable tool for you to have to know who does what with the data already in the organization. So we can go to our management and we can say, you know, the reason why when you ask Joe this question and you ask Mary the same question, you get different answers. It's because the data resides in different systems and is the responsibility of different people throughout the organization, and it has different definitions. This picture is worth a thousand words. It really helps people to understand why we've got the problems that we have around the governance of data as an asset in the organization. And oftentimes with it through the webinar, I share copies of the common data matrix, and I'm sure we'll share it as something with this webinar as well. And the interesting thing about the common data matrix and the operating model of roles and responsibilities that I showed on the previous page is that you can color coordinate them. You can see where the tactical level people are in the common data matrix. You can see where they are in the operating model. You can see where the operational people are in the common data matrix and in the operating model. These two components together around the roles and responsibilities become very critical for implementing governance within our organization. We need to have the structure set up. We need to record who these people are across the organization. So real quickly what I'm going to do is I'm going to go through the different layers of the operating model. Again, back in February, we did a webinar on roles and responsibilities around data governance. If you're interested in more details on this, there's a lot of additional information. I'm just talking about this as being one component of the program. Let's start at the operational level. These are people that define the data, that produce the data, and they use the data as part of their job. We can go as far as breaking down our stewards into definers and producers and users. A lot of organizations don't do that. They focus on people in the operational level. If they have a relationship to the data, we need to identify who they are. We need to record who they are into the common data matrix, and then we need to work with them to understand the impact that they have on the data and the rest of the organization. I talk about the operational data stewards and everybody being a potential data steward. The fact is, what are they responsible for? They're responsible for doing what is expected from them in their job and being held formally accountable for how they do it. Which really begs the question, what does it mean to be held formally accountable? I'll start with you when we get to the action plan part of the components here in a couple of minutes. Talk about how do we actively get them involved, formally get them involved in different processes across the organization. Real quickly, again, at the operational level, and we're going to talk about this more in an upcoming webinar, but I talk about everybody being a data steward. Here are some of the rules that I use for people becoming data stewards. The first rule is that a steward can be anybody in the organization, in fact. That being the data steward describes a relationship and it doesn't need to be a position. People aren't hired to be data stewards. They're data stewards based on their relationship to the data. They don't have to have the title of data steward. They don't have to be told how to do their job, but they do need to understand what their relationship is to the data. That public or industry data steward certification, to me, I think of it as being a load of bunk. Because really, we don't need to teach people how to do their job. We need to teach people how to manage their relationship to the data across the organization. There's more than one data steward for each type of data that has been into organizations where they've said, this person has this responsibility. This person is the customer data steward. This person is the product steward. The vendor steward. The first thing that I try to suggest to them is they really want to consider everybody in the organization could be considered steward. The fact is you may agree with all of those rules that I have. You may not agree with any of them. What I've been told by some people is it's basically a nobody approach because everybody, if everybody's a steward, nobody's a steward. I don't believe that at all. I do believe the first part of that, though, that everybody is a data steward and that they need to understand what their relationship is to the data. Real quickly, the data domain stewards are the people at the tactical level that are subject matter experts for the data. In fact, a client of mine recently told me that the data domain stewards are subject matter experts. We're going to call them subject matter experts. I completely understand that. We don't want to add additional complexities to the program where they're unnecessary. The responsibilities are what I have here. They are responsible. They may not be the authority for the data, but they are the facilitator of solutions around certain subject areas of data. They have responsibilities for escalating issues to the higher level, to the data governance council. They have responsibility for making certain that the rules associated with their data are recorded. The data domain stewards play a key role in the implementation of a program. Another role at the tactical level is the data steward coordinator. Again, there's more information about that but these are people that are associated with the business area that can help us to identify who the stewards of the data are, who the domain stewards are, subject matter experts of the data are. They act as a point communication person between the people on the far left side of the common data matrix and the everyday operational people within the organization. Again, this is not a webinar on roles and responsibilities, so I don't want to go into too much detail but one of the core components of data governance is defining roles and responsibilities that fit into the culture of your organization. At the top level of the pyramid or at least at the top part within the triangle itself is the data governance council. They're responsible for coordination of governance activities across divisions, cooperation, communications. These are folks in the organization that are at a high level that have responsibilities and are certain that data is managed as an asset across the organization. So the question becomes, well, what does the data governance council do? Well, they make decisions, they meet regularly, they identify and approve pivotal governance roles, they advise the council owner in making certain that the program is moving in the right direction. The data governance council for most organizations kind of sits at the top of the food chain when it comes to governance and people ask me how much time is typically required from people at that level. Typically I say 60 to 90 minutes a month for their meetings where we talk about governance issues, we talk about how the program is moving along, we're not necessarily solving data problems at those meetings but sometimes those meetings are 60 to 90 minutes a month, oftentimes they're bi-monthly or quarterly within an organization. The fact is the council needs to have to be working on governance and meeting to discuss governance and governance issues. They also need to have time to be available to read and review and comment on different things that are produced within the program. So I'm going to suggest that it's 60 to 90 minutes a month for council members for this activity as well. So now we're talking about two to three hours a month to get these folks involved. The fact is that there's also another component of it too. One of the things that I didn't talk about in the operating model is the arrow along the right-hand side of the pyramid. Issues get escalated from the operating level to the tactical level and then to the council level. Typically issues do not get escalated to the executive level. So the council needs to be there to solve issues when an issue gets escalated up to them and it's really hard to say how much time is going to be required for that. I heard some people say that the people on the data governance need to allocate 20 to 25% of their time to data governance. The fact is I've never seen that happen successfully in an organization at all. If we tell them that we need 60 to 90 minutes a month for this and 60 to 90 minutes a month for something else, they're going to be much more receptive to that than if you tell them they're going to need to spend eight hours a week focusing on data governance because, again, people at that level have responsibilities to go way beyond the data within the organization. Then there's the far left side of the pyramid. There's the data governance program team. There's the data governance partners, NIT, and I don't want to read through all of these before you hear them, but please take a look at them at your leisure. These are the responsibilities of the data governance program team to oversee the program, to architect the solution, to administer the program and if somebody has to have the responsibility for governance in order to move the program forward. I've seen organizations where the data governance team has been a dozen people and that's overkill for a lot of organizations, at least. I've seen organizations where the data governance team has consisted of one eighth of one person's responsibility. That's underkill if there is such a thing as underkill. We need somebody, as we talked about the best practices earlier, we need somebody in the organization that has the responsibility for the program itself who has a specific amount of time allocated to it, but we don't need to overfill that team. That team, their responsibility is not to fix the data. Their responsibility is to govern and to facilitate the management of the governance program. Again, they facilitate the governance council meetings. They have a lot of responsibilities. They deliver the educational materials. They provide QA and oversight to the program. They establish policies. They establish metrics. The data governance program team seems to be the most vital role, the most vital link in making a program successful. Somebody, again, like the second best practice I talked about earlier, has to have the responsibility for it and the data governance program. These are just a list of some of the responsibilities of the data governance program and I hope that they're helpful to you. Also along the left-hand side of the diagram is the data governance partners, IT or your project management office or your regulatory and compliance areas. They have responsibilities as well. They have responsibilities for focusing on consistent protection of the data, responsibility for project management, to meet classification requirements and other data requirements, securing the infrastructure. All of these things that I have listed here, I call these people data governance partners because that's what they really are. People ask me all the time, should governance reside in business or IT, and my answer to that question is yes, it needs to reside somewhere in the organization. It can reside in either. As long as it's not sold to the organization as being an IT initiative for IT's sake, then I've seen it be successful with data governance initiating out of an IT area. More often than not, it comes out of a business area, but I wouldn't rule out that if data governance focuses, or at least is being facilitated by your IT area, that you're not going to be successful, I don't believe in that. I believe as long as you identify the appropriate stewards from the business side and get them involved appropriately, then you can be successful no matter where your governance program resides. Information technology, what role do they play? They make certain that governance is built into our standard project methodology. They help us to understand that the strategic data needs to be modeled and named and defined consistently across the organization. We have a common semantic layer and a vocabulary for the organization. They ensure that the project sources and utilize data as much as they can from the systems of record when it comes to master data management and business intelligence. They provide technical support again. I don't want to read through all these things, but information technology, if we don't take advantage of their knowledge of the data, then we're making a big mistake because a lot of the knowledge about the data resides in the information technology area. I know I've spent about 10 minutes here talking about this one core component of the framework, but roles and responsibilities seem to lie at the core of everything we do. You'll see that in the next two components that I'm going to talk about, the communication plan and the action plan. We need to make certain that we understand the different audiences that are associated with our program, and we need to get them engaged from an action plan perspective, from a racy perspective when it comes to getting them actively involved and when it comes to applying governance to processes and procedures within the organization. So there, I kind of beat up the second component quite a bit. I talked a lot about roles and responsibilities. I'm not going to talk as much about communication planning, but I am going to do one thing. I am going to emphasize the importance of communications to a successful data governance program. And over my years of working with organizations, I've found that there's really three different types. Actually, there's a lot of different types of communication that takes place, but there's three different categories that I use to define what successful communications around data governance looks like. And it just so happens that all three of these start with a letter O. So I have the three O's of data governance communication. So there's orientation communication for people that are new to the organization or who are just being introduced to data governance. There's onboarding communications, and that's a term that I hear used fairly regularly, of getting people onboard and getting them to understand what exactly is their role in the program and when they get engaged and when they should engage the data governance team in the different initiatives throughout the organization. And then there's ongoing communications. And as I mentioned before, I have a lot of different templates and tools that I use to describe these components. Here's a model that you should feel free to use that is, again, it's a two-dimensional spreadsheet or two-dimensional diagram or matrix. And what it does is down the left-hand side of the communication plan, we have the different types of communication labeled. So under orientation communications, again, just giving people information about the program. Under onboarding communications, what are best practices and what are the principles that we're following for governance? What are the books of business value that we're going to get from governance? And what are the role-based activities associated with the role that they're playing within the program? And then the ongoing communication is alerts and triggered events. Something happens that causes data governance to get involved. What are those things? And how do we get people to recognize when is the appropriate time to get your data governance program team involved and to get your stewards involved and your domain stewards and basically invoke the program to help to solve the data problem. So there's a lot of alerts and triggered events, things that cause data governance to happen. There's council information in meeting minutes. There's governance documentation and metadata. All of those things are ongoing types of communications. And the fact is that we can't communicate all of these things to all of those different audiences that are listed across the top of the matrix. We can't communicate them the same way. So we may be able to use certain tools for certain audiences and we might need to summarize the message for certain audiences. And all this diagram really helps us to understand is that around the different core types of communications that we feel are important, we need to make sure that we have a plan for communicating that to all the different audiences that we just defined in the operating model. And again, what I'm trying to do here with the colors on this diagram is make the colors apply consistently across the operating model or across the common data matrix because then once somebody recognizes where they fit into the overall program, they can see where they fit in the communication plan. And in a moment when I start talking about the action plan, you'll see where they fit in the action plan as well. So again, color coordination becomes very helpful in getting people to understand the consistency of how we've defined these components across the organization. Again, a lot more information is available about communication planning. If you're looking for more information, please reach out and I'll be glad to share with you anything that I can about what it takes to put a successful data governance communication plan into place. So the last core component and then I want to leave some time for question here at the end are is doing the action planning, building that action plan and that roadmap for data governance. And typically when I talk about action planning, I talk about it in terms of being proactive and in terms of being reactive. When we have a problem, how do we address that problem? Well, that's reactive. When we build governance into what we are doing, I call that being proactive. So most of your organizations probably have system development, lifecycle methodologies. My suggestion is that rather than redefining that methodology, let's apply governance to it. Another one of my pet peeves that I talk about a lot is these things called data governance processes. Well, let's not call them data governance processes. Let's call them processes and let's apply governance to them. So if we have a system development lifecycle methodology or we have a certification process for data that's entering the data warehouse, rather than calling these things governance processes and having people point at governance for the reason why we're doing these things, let's just call them the processes for whatever they are and then apply governance to them. So again, let's not point at data governance and get people to think that data governance is the reason why things are being slowed down, that due diligence is being played are applied across every step of a project. We want to make certain that we govern the process that we don't have to call them governance processes. Again, just one of my pet peeves around some terminology that's used in this industry. I know this diagram is very difficult to read. I call it a data governance activity matrix, but if you look at it, down the left-hand side of the diagram is pretty much a system development lifecycle methodology, really one for master data in this situation where there's a core of different steps of things and then across the top we have the different roles and we can specify what role each plays in the steps of the methodology. So again, rather than applying, saying that we're going to call this a governance process, let's apply governance to the processes and let's do it in a structured manner like the one that you see in front of you. Another example of that is one that I commonly use and I've used in other webinars in the past, which is let's build a spreadsheet. So in this diagram here along the left-hand side, you see we list six different processes that need to be governed across the organization. If you clicked on any one of those processes, Inwood slide or Inwood pop-up on your spreadsheet, these are the steps to follow this specific process. These are the different roles. If you're familiar with RACI, responsible, accountable, consolidated, or informed, my suggestion is that we're going to, again, apply the roles to the different steps of the processes that we're governing as part of our governance initiative. So again, we're going to be proactive in building these steps into the things that we're doing in the organization. The other side of the coin is reactive side, where we have an issue, we have a data quality methodology, we're going to apply it to specific examples and specific problems. Take the steps that you have of your data quality methodology and apply governance to them. So if this is just an example of some steps that may be included in your data quality methodology, consider building a matrix or something like this that says, okay, here's the steps that we're going to follow for data issue resolution. Here's the different roles that we defined in the operating model earlier on in the webinar, and we applied to it who's responsible, who's accountable, who's consolidated, who's informed. I've seen some organizations that have added the S to RACI and made it RASCII, and in fact, that's a supportive role when it comes to data governance. So again, the idea is to apply governance to your processes rather than calling them governance processes, and let's demonstrate to people that we're already governing data, we can do it better, we can do it more efficiently, we can do it more effectively, and we can do it more formally, which really comes back to the definition that I used at the beginning of the webinar. So just to wrap up real quickly, before I take a couple questions here, is the data governance framework components that I talked about consist of these things. They consist of best practice, operating model roles and responsibilities, building a communication plan, and building an action plan. So those are the things that we talked about if you're interested in learning more about them, please reach out to me or reach out to me through J-Diversity, and I'll be glad to talk to you about those. So those are the things that we covered today. Being to think that Shannon may have dropped off or might be having a technical problem. So what I'd like to do is I'd like to just read through some of the questions myself while we're waiting for Shannon to get back and see if we can address a bunch of these questions in the 10 minutes that we have left. So the first question that I see here is what would you consider the first steps needed to be done after the CIO says that he wants a data governance program? Well, the very first step that I would follow is that I would identify somebody in the organization and give them the responsibility for governance. I know I talked about the very first best practice being that senior management needs to support sponsor and understand what it is we're doing, but the second best practice that I use is that we need to give somebody the responsibility for doing this. So the very first step that I would do, and you don't even require a budget, even at that point to get started, is give somebody the responsibility for starting to define the program, excuse me, for starting to define the best practices, the roles and responsibilities, those types of things that are going to be necessary in order to make the program successful. The second step might be to either to develop a team or to develop those best practices and then start doing the analysis. So rather than trying to shoot at a target that hasn't been defined for you, let's do a ready aim fire rather than a ready fire aim. Let's define best practices, find out what we're doing that supports it, where there's opportunity to improve, and then put our action plan in place to start to address those things. Second question that I see here is, do you suggest ROI or cost-benefit analysis to justify allocating resources to data governance? Well, in a lot of organizations, yes, they need to have return on investment or they need to understand what the benefit is versus the cost of building your program and putting governance into place. I've seen organizations that have started by putting a cost to the quality or the poor quality of their data. For example, an organization that I worked with recently focused on returned mail because their customer addresses hadn't been defined and they found that they had been spending millions of dollars on mailings that were going out and that were being returned to them and there was a cost associated with the printing, the distribution, the wrapping, even on the returned items, they did do a cost-benefit analysis first or they tried to specify return on investment. The truth is that I don't tend to focus on return on investment as much as I tend to focus on other things. I think that if we need to manage data as an asset, if we need to govern data to follow the rules and regulations that are being defined for us, that it doesn't need to have a return on investment. It just needs to make certain that people understand the rules that we're executing and enforcing on the rules that we have associated with the data. A lot of those rules tend to come from the outside rather than be things that we define internally. I suggest ROI and cost-benefit analysis as much as possible if that's something that your organization has an appetite for. Next question that I see on the list is what impediments have been in the support to get senior management? I think one of the biggest impediments to senior management supporting what we're doing is to get them to understand how we are going about putting the program into place. Everybody hears the term data governance. They think of the term governance. They go running to the hills because they think that it has to be about command and control. The fact is it doesn't have to be about command and control. In fact, we want our senior leadership to understand that there are alternative ways to putting governance into place. Please share with them the idea of being non-invasive in the approach to governance. That seems to help quite a bit as well. Shannon, are you back with us? I love it when technology doesn't work. I've been going through the list of questions. Would you like me to continue? I have no idea where you are on the list, so sure. That's very good. Technology is a wonderful thing when it works. I want to continue down the list. Where does data quality fall in the data governance framework? Well, actually, data quality falls throughout the framework. Again, the framework includes the 10 or 15 or 20 components. The quality has to be a piece of each and every one of those. I limited it down to four, that we need to have quality best practices. We need to have quality in our operating model, our communication plan, and our action plan. But the action of data quality, I find it very difficult to believe that organizations can be successful in implementing data quality unless they positively affect the behavior that people have around the data. One example that I use of that when it comes to data quality is these things called what I call cheeseburger definitions. What's the definition of a cheeseburger? It's a burger with cheese. What's the definition of a patient address? It's the address of a patient. In fact, I'm working with a client right now who's a little bit struggling with their data dictionary and their terms. But if we want to have quality definitions for our data across the board, the idea would be that we spend time and we focus on making certain that the definition is defined for our organization, for the business community, how the data should look and what the data needs to look like when it comes to using that data either operationally or for reporting. See, there are any additional questions. You know what? I think we're good then. I think that's the majority of the questions that we had. Please, we're going to stay online a little bit here. So if you've got additional questions, please feel free to enter them into the Q&A section down on the bottom right, as Shannon always says. And I will make certain that I will address these questions for you in the writing form in the follow-up that Shannon will provide in Two Business Days from today. So where do you want to add, Shannon? Yes, which brings us to the most popular question that I always get, and that has come in certainly throughout the webinar. Just a reminder that I will be sending a copy of the slides and the recording within Two Business Days. So for this webinar, I will be sending it out by end of day Monday. And also, for this particular webinar, as Bob says, we'll get the answers to your questions in written form, along with copies and links to the matrices that Bob has presented throughout the webinar. So you guys will have all of that information. And so that is it. And Bob, thank you so much again for such a great presentation, as always. And thanks to our attendees for being so engaged in everything we do with such great questions and participation. So, Bob, before you log off, though, I need a favor, but otherwise, I hope everyone has a great day. Okay. Thank you, everybody. See you again sometime.