 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining the current installment of the Monthly Data Diversity Webinar Series, Real World Data Governance with Bob Siner. Today, Bob will be discussing a complete set of data governance roles and responsibilities. Just a couple of points to get us started. Due to the large number of people that attend these sessions, he will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom middle of your screen for that feature. For questions, we will be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag RWDG. And as always, we will send a follow-up email within two business days containing links to the slides and the recording of the session and additional information requested throughout the webinar. Now, let me introduce to you our speaker for the series, 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 DAMA 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. Hi, Shannon. Hi, everybody. Thanks very much for taking time out of your schedules to attend the webinar today. Hope you're having a good day wherever you are. This is a fantastic subject that I feel is really the backbone to successful data governance programs everywhere. It's very important that we start with a very solid definition of what the roles and responsibilities are associated with data governance. So I'm going to share with you a lot of information today and so let's kind of get started. We'll jump right into it in a second here. As I get started, I always like to start by sharing with you some of the ways that I'm going to be involved in the data governance industry for the short term and the long term. As always, the monthly webinar series, the real world data governance series, next month we'll be talking about building an effective data governance framework. And I'm going to allude to that during the session today. Of course, there's always the non-invasive data governance book. I'll be speaking at a couple of data diversity events coming up soon. The first one is in early June, the data governance information quality conference and I'm also going to be speaking at the data architecture summit in October. I really want to let you know about two online learning plans that are available through data diversity. The first one focuses on non-invasive data governance. And the second one, which was just introduced at the beginning of the year focuses on non-invasive metadata governance. And then there's always the publication that Shannon mentioned, the data administration newsletter and KIK consulting, which I consider to be the home of non-invasive data governance. So let's get started. What am I going to talk about today? Like I said, I'm going to share with you an end-to-end complete set of roles and responsibilities associated with your data governance program. So I'm going to talk about a whole bunch of different levels and why we need to have different levels of participation within the program, everything from the executive down to the operational and support levels. We'll talk about how to customize a model that I'm going to share with you. The operating model roles and responsibilities will go through the detailed responsibilities and who needs to participate at each level. And then last but not least, I'm going to talk about something that I'm finding to be really effective in a lot of organizations right now. It's the use of working teams. And I'll share with you who goes into the working teams and what exactly do we ask the working teams to do. So let's get started. The first thing I said I wanted to talk about was the different levels of roles and responsibilities that are associated with a data governance program. If you've attended my webinars in the past, you've seen what I refer to as the pyramid diagram or it can be referred to as the operating model, the steward diagram, or just a set of roles and responsibilities. It goes by a lot of different names and the fact is that typically the set of roles and responsibilities is going to be very different from one organization to the next, but they have some core components that are pretty consistent, at least from what I'm seeing being very consistent within organizations that are implementing successful governance programs. So I'm going to walk through each of the different levels and each of the different roles that are associated with each of the levels. The pyramid diagram that I mentioned I have it on the screen now in front of you. And as I said it looks kind of complex. It looks like it's got a lot of moving parts and the fact is that when I get to the part of the webinar that talks about how you customize this specifically for your need, you're going to want to highlight the things in the model that already exist within your organization and what are the things that we can leverage and also let people know which parts of the model are new and it's going to require some additional resources potentially within your organization as you're getting started with rolling out your programs. And like I said, the roles and responsibilities sit at that backbone core of successful programs because if we're developing communications, we need to know who we're going to communicate with. If we're putting together some formalized processes and who's accountable for the different steps of the processes that also refers back to the operating model. So this is really a core component of a successful program and we're going to go through each of these different levels in detail moving forward. But before we do that, let's talk about each of the specific levels and why they're important. Well, typically I use this setup. I typically define executive roles and obviously they're not going to play a large role in the active day-to-day operationalizing of your governance program. The strategic level which oftentimes is referred to as the Data Governance Council. The tactical level which are typically the subject matter experts of people in your organization. Who do we go to when we have a question about a specific type of data? The operational people are the people that are day-to-day defining, producing and using data as part of their job. And then I'm going to go through the support functions. IT could be considered a support function, audit, legal, all of those different entities that have a vested interest in your being successful with your program. They all fall in at the support level. And the truth is that not all organizations define their levels in the same way. I had a client not too long ago that wanted to swap the operational and the tactical. They said that the tactical was really what I considered to be operational and vice versa. But the fact is that this really needs to be customized per your specific situation. And I've had organizations that have said, you know what, we need to get rid of some of those levels. We need to simplify, simplify, simplify. And the idea is that you're going to need to have these different roles no matter how you set up your program. Whether or not you classify them by the different levels of the organization, it really depends on your organization and what you call the individuals and the groups at the different levels of your organization. So let's start at the very top of the operating model. And that was the executive level. That's typically the tower that sticks out of the top of the pyramid diagram that I shared with you earlier. And you may ask why is it just a tower and why doesn't have any space in it? And the truth is that the amount of space that's identified in each of the different levels of that pyramid diagram, they mean something. Typically it represents at least approximately the percentage of decisions that we take to the different levels. And oftentimes we don't take this data decisions to our executive level. So that's typically why there would not be a space within the executive level of the operating model, because it is really the highest part of the organization. And what I suggest is rather than giving them a new name like calling them the data governance steering committee, there have been some organizations that have done that. But I'd go with whatever they're already called. So when we ask the question of what should we call these people, the first thing that we should do is take a look at what are we already calling these folks? And can we leverage them the way that they exist? So potentially you can call it a steering committee or senior leadership or risk management committee or whatever name you use to talk about the executives that get together from time to time and set the direction of the organization and can also be the ones that set the direction for data governance within your organization. At the strategic level, now that was the top part of the pyramid actually, not the tower that was sticking out of it, that's called the data governance council or an information governance program team or a practice council. Again, look to see if you have representation like the ones I'm going to talk about as we move forward in this webinar as to who the people are that are representing this group or this portion of the model and let's see if there's something that we can leverage and then call them what they're already called rather than creating a new group. But oftentimes that strategic level, that data governance council becomes the ultimate decision maker and actually the ultimate direction giver to the data governance team or whoever has the responsibility for moving your program forward. At the tactical level, I usually talk about the tactical level as being the most difficult to fill but actually in reality in a lot of organizations we can already identify who the people are in the organization that are decision makers or are the authorities in certain subject matters of data. I always refer to them as data domain stewards but I have a client recently that said well what you're really talking about here is the subject matter experts, the enterprise data subject matter experts. I said yeah in reality that's what they truly are and we'll talk about what they do in a minute but the person from this organization said well that's what we're going to call them. So don't feel like you have to go with any of the names that I'm sharing with you but the idea is that at the tactical level we need to have people that represent the ideas in that subject area of data across the organization rather than specifically within one specific business unit. You can call them data domain stewards, enterprise data stewards, enterprise data subject matter experts. Again, look to see what do we typically call somebody in that role within our organization and use that name before we start introducing new language to the organization because you don't want people to spend most of their time asking well what does this role do? Well if you say that enterprise data subject matter experts then it pretty much defines what we're going to ask from these people. So again think about what we're going to call the people at each of the different levels of the pyramid diagram. At the operational level the bottom part of the pyramid diagram and I will show the pyramid diagram some more in a little bit as I go through the specific roles and responsibilities but at the operational level that's where the data stewards reside or you could call them the operational data stewards if you want to differentiate them from the data domain stewards who are your subject matter experts. And for some organizations they'll actually define formal accountability based on people's relationship to the data. So if somebody defines data let's define what their responsibilities are that are associated with defining the data. If they produce data the same thing. If they use data we need to make certain that every single person in the organization that uses data that needs to be protected is aware of the rules associated with handling that data. We don't want to go to our management and say well we've got these people over here and they had to understand how to use the data but everybody else you know it's the Wild West. No the fact is that anybody who uses data that needs to be protected needs to understand what the rules are associated with handling that data and then potentially anybody that defines produces and uses data could be a steward and if you've seen my webinars before you know that I've said that everybody in the organization could be a data steward. I typically say everybody is a data steward over it. Well anybody that has a relationship to the data as a definer producer or user of that data if you're going to hold them formally accountable for how they define produce and use data they potentially can be a data steward using the non-invasive approach. Again we're not looking to go to them and give them more than what they already have we're going to focus on formalizing their level of accountability based on their relationship to the data that they're defining, producing and using. So what are we going to call these people? Do we have to call all these people data stewards? Do we have to let them know that they're data stewards? Well the fact is you really don't. I mean you can let them know that they're stewards and then the level of accountability comes along with the actions that they're taking but these are people in the organization that day to day are defining, producing and using data. We don't need to change their titles we definitely don't want to change all of their titles because it relates to how they get engaged in the data governance program they may be considered to be data stewards or operational data stewards. So figure out what's the best name to call them or do we just use the titles they already have when we start to roll out the program. The support level is kind of interesting. There's a lot of different components that can make up that support level and that the support level was actually what was on the diagram on the left hand side of the diagram kind of the two diagonal bars going up the side of the pyramid and that first of all it needs to consist of at least the person or the people that have responsibility for your program. So whether that's an administrator as it's one person or part of one person's job to a data governance office to a program team whatever you are labeling the people that have responsibility for moving governance forward that is one of the most necessary support levels that we've talked about in the past as a best practice. If you don't have anybody that formally has responsibility for your program your program is going to be at risk immediately. So those first three bullets under support are that function or kind of the administrator, the office, the planning and program team which a lot of organizations need to focus on making certain that they have resources at least to administer the program. The other support levels the IT systems, the IT security, risk management project management all of those listed could be partners of the data governance program if we need to get them involved. So for example let's pick the last one communications. Let's say that the people on the data governance team are not skilled in marketing and communications and that's often the way that it is. So it makes sense to bring in somebody from the communications part of the organization that can help you to refine your message so that your message is resonating in the best possible way with the people that you're sharing your message with. You can look at data governance as almost being a campaign where you need to campaign to the organization and let them know what is going on with data governance, what their role is and somebody needs to do that and you've got a lot of governance already taking place in your organization. Risk management, project management these things are all a level of governance certainly IT security so we want to recognize our partners for what they're presently doing within the organization. All right now let's shift gears a little bit because I kind of walked through the different levels of the organization but I want to talk about some best practices that would be associated with taking this model and applying it to your organization. So the first best practice that I want to talk about is that instead of trying to take your organization and plugging into this model my suggestion is in fact exactly the opposite. Take the model and overlay it over what already exists within your organization. If you've already got a steering committee then let's recognize them as the potential steering committee for data governance. If you've already got stewards or people that are defining producing and using data as part of their job then they already exist but we need to recognize who they are and start to engage with them as being true stewards of the data. So my suggestion is don't try to plug into this model. Use this model and overlay what already exists within your organization and it's going to become a lot less invasive to your organization because you're not going to be creating as many new groups or new roles and new names and such for different people that are playing different roles within your program. As I mentioned before that these two parts of the pyramid diagram start thinking about using names that already exist within your organization. I went through a couple slides of what should we call these people. Let's look for what they're already being called now, what their role is presently and let's use those as the names of the roles at least to get started. If it makes sense at some point to change your risk management council to data governance council because they're focusing more on data governance but we're starting with the risk management council because it is very similar to the makeup of the other council then you want to make certain that you're recognizing the names that you're presently using and change them when necessary but at least to start use names that are already familiar to you and already familiar to your organization. I mentioned this before as you look at the model for the first time as you look at the pyramid for the first time the first response might be wow there's a lot of different levels and this is a lot of new stuff that we need to create for our organization but if we add to our diagram what already exists and what's new and what we can leverage it should decrease some of that fear of people within the organization. So they look and say okay well the data governance administrator in the upper left hand side that's new that's a role we know that we need to play or have somebody play but the data governance partners they're already existing in the organization. We'll talk about the working teams in a little bit but also going down the right hand side that already may already exist but the council might be new. You might leverage your subject matter experts. Again the verbs that I'm using here or the pronouns that I'm using here actually reflect your organization so don't use what I'm providing use the things that make sense to your organization and if it's new call it out as being new. You might do presentations that just focus on the new pieces to help people to understand what all the different moving parts are within the data governance model for your organization and the last thing is really the last best practice or one of the last best practices is you know adjust this is necessary. I had a client that took it and turned it into nine layers and they had a lot of time describing the difference between layer six and layer seven. So what I suggest again look at the levels that I just defined the executive strategic tactical operational and support because they may potentially be being used already within your organization but once you've identified what are the different roles we need to say who are the people in the organization who are going to participate in those roles how much of their time and what exactly is it that we're going to ask them to do as we get them engaged in the data governance program within the organization. And actually I think there's one more best practice I want to share with you and I'm not going to spend a whole lot of time talking about this in the webinar today the common data matrix. If you've read the book non-invasive data governance or you've read the or you've listened to webinars in the past or seen me speak at diversity events I spend a lot of time talking about the common data matrix and what it basically does is it helps you to inventory who's doing what with the data across the organization. If somebody asked a question that needs to be answered with data and they ask it to two different people in two different parts of the organization this diagram can help you to understand why you're getting different answers because people are using different data or their understanding of the data is a little bit different. So the common data matrix is something that we usually share with everybody who attends the webinar. It is a very valuable tool but what I'm suggesting here is the best practice is that we can work in reverse. We can work from the common data matrix and start recording what areas of the organization are using what type of data and who has responsibility and who's the subject matter expert. We can start from that end and work our way backwards to define what are the different roles and responsibilities that are necessary for our program. So we talk about each of the different levels just briefly. What I do want to do is I want to share with you since we're giving you a complete set of data governance roles and responsibilities what some of the responsibilities are that are typically associated with the different levels of the pyramid and for that I'm going to have the diagram pointing to which level of the pyramid it is that I'm talking about. The truth is it looks like there's a lot here for the executive level, the enterprise leadership but the truth is this is not a list of responsibilities. Typically this level of the governance model is made up of people at the C level of the organization and like I said before there might be a committee that already exists. We're not going to give these people specific day-to-day or monthly data governance activities except they are going to be reported to. What is the status of the program? How is the program working? Is it doing what it's supposed to if we have people that are not willing to participate then we need to report that to them potentially as well. But these folks again aren't engaged day-to-day. They're reported to and it's really good if they support sponsor and understand data governance. In fact I typically share that as the very first best practice is that without senior leadership support, sponsorship and understanding your data governance program is going to be at risk immediately. So what we're going to try to do is we're going to try to get on the agenda of those meetings and if data governance or representation from the council becomes part of the agenda item on those meetings it becomes very helpful. That way we can continually keep the people at the executive level up to date on what's happening within our data governance program. Alright so we're going to spend a little bit more time than we did on the executive level. We're going to talk about the strategic level and oftentimes that strategic level is thought of as being the data governance council or something similarly named. And oftentimes the executive level that we just spoke about identify or recognize people that they want to reside at the strategic level. We'll talk about some of their specific responsibilities here in a minute but these are folks that have a vested interest in seeing governance be successful. Like I said before they're aligned with the executive members they typically have direct accountability to those executive levels and what I suggest is that if you're going to have data governance council meetings then every part of the organization would be asked to attend every meeting. And if that means that we need to have an alternate or somebody to stand in for somebody who's on the council if they're not in attendance you know typically in the organizations that I work with I suggest that everybody is represented on the data governance council. So oftentimes we need to have that stand in and now let's talk a little bit about what we're going to ask those people to do. So typically the way I describe it is that the data governance council consists of strategic representation of both the business and IT. We need them because we need to pull together the silos of the organization. And I'd love to hear how many of your organizations have silos. I tend to hear that from pretty much everybody and if we're going to govern data as an enterprise asset we want to look at you know being able to have cooperation across the activities across the divisions or business units of the company. We need to have cooperation and communications and comprehensive risk management. All these things with the data governance council they're at that strategic level to make certain that the people within their parts of the organization are doing what they're supposed to. So let's talk about a little bit about what a data governance council does. And the first thing that they need to do is become educated in data governance which means that we need to have some meetings early on to help them to understand what role they play but also to understand the approach that we're taking to governance within our organization. So we need first and foremost to get them educated on what it means to have data governance in place, how it can and will work within the organization so that they can help people within their parts of the organization to stand behind and activate as it comes to as it comes to that part of the organization. The data governance council also approves things that get they get escalated to their level and they're also responsible for pushing data governance into their areas and so the fact is it sounds like we're going to be asking them a lot of things to do but the fact is that I get asked the question a lot how much time should we expect people with the council to participate and I'll share that with you in a minute. I know you don't want to estimate too high because they don't these people they have much more to do than just worry about the data governance council. It really needs to be directed to communication when you're working with them and get it to them quickly so that they understand what is needed from them. So what else does the council do? They make decisions at a strategic level. They meet regularly. They identify and approve the direction for the organization. They advise the council owner or a person who's directing the council as to what's of interest to them. Maybe we need to focus on a new aspect of data governance and that's protecting sensitive data or maybe we need to improve the understanding or the quality of the data. They're the ones that might be in position to be able to advise you as to what the most important things are for your data governance program to be doing. So now comes the question of how much of a time commitment is there for people with the data governance council level and the fact is if you ask for too much they're going to laugh at you because this is not their first and foremost activity. I had somebody come up to me at a conference recently and say that somebody had instructed them that data governance council members should spend 25% of their time on data governance and the fact is that's ridiculous. I mean I told them when they go back to their organizations and say that you need 25% of these people time for data governance for the data governance council when they're done laughing at you you could share with them what you really mean and I'm going to share that with you right now. So if you're going to have once a month meetings or once every month other month meetings they number one need to be able to allocate the time to attend those meetings. So right off the bat we were expecting that maybe 60 to 90 minutes a month could be asked of the council members at least as a start just to get them educated and knowledgeable in what's going on and what their role is going to be in successful governance within the organization. They also need to have time to review and read and comment recommend and approve different things that you're sending to them. So whether it's your data governance policy and your mandates or even your operating model of roles and responsibilities they need to have time if you're going to take a new data governance information governance records management policy to that level to be approved they need to make certain that they know that they have time to be able to be allocated to focus on these things. So so far we're talking 60 to 90 minutes for a meeting we're talking 60 to 90 minutes to review things and this is on a monthly basis we're not asking for them to do things daily but there is a potential that they could be asked to do things that are outside of attending meetings or just approving things that we're sending to them and that is that they're the ultimate decision makers when it comes to issues that are escalated from the operational to the tactical and then to the strategic level again we're talking about the strategic level of the organization they need to have a bit availability to resolve the data issues that are escalated to their level whether that's five and typically I suggest that that's five to 10% of the issues that get escalated to that level. If all of your issues need to be resolved by your data governance council I typically say that there's a deficiency in the tactical level of your program and I'd love to talk to you about it if you wanted more information about what that means it just means that you're taking every decision to your strategic level it shouldn't be necessary you should have some level of authority within the tactical level of your organization as well. So typically when they hold the meetings we're not solving data governance issues at the council meetings this is time beyond the meeting time to become educated and the approval of things that we're sending to them so this could be and this is really going to depend on the number of issues that you're escalating up to your data governance council level. Alright so let's talk about the tactical level for a little bit so the data governance council plays a key role but again they're not necessarily engaged day to day the people that they could be engaged day to day are at the tactical and the operational level so let's talk about them for a couple minutes here. The data domain stewards are the subject matter experts or the custodians or whatever you want to call them within your organization that's one of the key roles that take place or participate at the tactical level. I also talk about data steward coordinators who would be people within certain parts of the organization that coordinate the activities or coordinate communications with the stakeholders and I'll spend a second talking about them after I get through the subject matter experts or the data domain stewards. So let's talk about what are some of the specific responsibilities for the data domain stewards and so typically they are not responsible for looking at data from just the viewpoint of one specific business unit they are more responsible for looking at the data as an enterprise asset and making decisions that potentially affect multiple people across the organization. Now the fact is that there could be multiple subject matter experts who you need to get together and have conversations to resolve issues that are pertaining to data that's being used by everybody in the organization. So typically these people are identified by position so for example within a university it could be the registrar that's responsible for student data or the bursar that's responsible for financial data that might have policy within your organization that states who the domain stewards are, who the subject matter experts are. So certainly look to see if you have that. And the fact is when they're acting in the role as the subject matter expert their affiliation to their business unit should really become secondary because again they're looking at the data from a cross business unit perspective rather than by a business unit by business unit specific level. They've evolved their facilitator and bringing the resolution to issues pertaining to the definition production and usage of data. And as I mentioned before they could or they could not be the authority or the decision makers. If they are the decision makers and we're escalating an issue up to them then we don't need to take those issues to the data governance council. We might need to educate the council on the fact that these issues existed and that they took place but the data domain stewards play a critical role because again they're the ones that are looking to break down the silos and try to get data to be consistent across the organization. So some more responsibilities for the domain stewards are that they're responsible for escalating those issues to the strategic level if they need to, if they can't make the decision themselves. They may have some level of responsibility for documenting classification rules compliance rules, business rules or they might delegate that to somebody in their part of the organization to document those things. They can be responsible for making certain the rules are communicated, rules RULES are communicated and oftentimes the data domain steward or the enterprise subject matter expert is engaged in the working teams that I'm going to talk about when we get to the end of the presentation here. So what are some of the typical traits of people that make up good data stewards? And I just wanted to share a couple of them with you here. First of all they have a vision of what data, the future of data looks like. They're looking to improve the way things always have been within the organization. They have the ability to motivate and they're setting good example of data related behavior. Definitely the most important perhaps is that last bullet which says that they have the personal interest, the intuitive ability and the communication skill to facilitate conversations with people from across the organization to the best ability to achieve a win-win within their organization. And so let's talk about the steward coordinators which sit at the top of the columns in the common data matrix that I shared earlier and as I mentioned before they can act as a point communication person with the data steward. So instead of the domain stewards communicating to all the different people in the organization that are data stewards we would want to go potentially to the steward coordinators from each function and share with them the information that has to be shared with the stewards within that part of the organization. They typically get involved in identifying the operational stewards working with the domain stewards to make certain that a project is being completed on time and on budget. A steward coordinator typically doesn't have decision making authority but they play that pivotal role in making certain that people are communicating effectively with the data stewards of the organization. And last but not least there's the operational level and actually we'll talk about the support level here in a minute but the operational level as I talked about before anybody who defines or produces or uses or defines and produces and defines and uses any one, two, or three of those three actions if they're being held formally accountable for what they do with the data potentially they could be data stewards. So it could potentially be everybody in the organization let's talk about what these folks do. Actually before I get started I wanted to share with you a real quick list of what I call signers rules for becoming a data steward. Everybody has to have something named after them. So this is signers rules for becoming a data steward. The first one is that a steward can be absolutely anybody in the organization and that really being a steward is describing what people do with the data. It's not a position. You don't have to hire people in to be data stewards. A data steward doesn't need to be called a data steward. It can be called whatever they're already called within the organization. Oftentimes stewards don't need to be told how to do their job except for where there's deficiencies where they're not doing things that are in the best interest of the organization. I don't like the idea of public certification of data stewards because it really the stewards do what they're hired to do by the organization. They're not hired to be data stewards. They're hired to perform a function and that function defines, produces, or uses data as part of that function. Also instead of saying there's only one data steward for each type of data, the fact is that there's as many data stewards as there are people that have relationships to the data. You might have multiple people defining the same data in different parts of the organization. People that have the responsibility for producing the data and using the data is the no brainer. We're going to know that we're going to have a lot of different data stewards and we need to set up our program in such a way that it counts for the complexity of just not having a handful of data stewards. It deals with the complexity that potentially everybody in the organization is a data steward. I just want to go back to that one slide for a second. The number eight bullet point in these rules is extremely important as well. If we're going to talk about how we're going to train the stewards within our organization, if we focus on formalizing accountability for things that they're already doing rather than coming to them as something that's brand new to them, that's how I suggest being as non-invasive as possible. Let's look to what they do. Let's help them to do it in a better way or in a way that's going to be better for the organization before we start handing them additional things to do. We're going to formalize accountability that perhaps should already be formalized, but we're going to do that in a very non-invasive way in the organization. One of these operational data stewards do, we've got people that are defining, producing, and using data. We need to make certain that they understand what are the best ways to define and to produce and to use data. As people who have that relationship to the data, if we can now help to educate them on what that means and where it's really beneficial to the organization, that becomes extremely important. Some other things that the operational stewards do, they participate in definitions, they participate in producing the data, all of these things. I don't want to read through them but I'm glad to say that you will get copies of the, or you'll get a link to the slide so you can see them later, but there's a lot of different things that stewards are already doing with data and if we can help to formalize their accountability for what they're doing and not come at them with a club and say okay, you've got all these additional things you need to do, they may be much more willing to listen to you and participate in governance and stewarding activities. If you say you know what, you're already doing this, we can help you to do it better. So now let's talk about the left side of the pyramid diagram and that's the data governance planning or program team, the data governance administrator, and then the data governance partners, which oftentimes IT is one of the biggest partners that data governance has. If you think about it from the diagram perspective, everything that's in the pyramid, the triangle part of it, including the tower sticking out of it, oftentimes those are business roles but we need to get the technology folks involved and they have a lot of knowledge of the data and a lot of knowledge of the systems and in fact I've been told by a lot of organizations that the stewards of the data are in IT and I know that that's trying to change in most organizations. So if we think of the fact that the two stewards are people within the business units that are defining, producing and using data, then IT plays a different role. They could be data subject matter experts pertaining to specific data within a specific system or they could be system subject matter experts but IT is typically one of the first partners that works with the data governance planning or program team as you're moving forward. Other potential partners include risk management or project management. If you think about it, IT security and all of those things, that these are organizations that could potentially be called governance organizations already as you're getting started because my suggestion is to tell your management that data governance already exists or we're already governing data, we're just doing it very informally, inefficiently and effectively and things like that. So what we want to do is recognize people for what they do and give them a role to play within our governance program instead of again piling on to them and giving them a lot more work to do. So let's talk about what's the responsibility of the administrator or the office or the planning team of that group. So typically, what I found with organizations is that they have a data governance planning team that evolves into a program team. So if you think about it during the planning phase, we're going to engage people at tactical and strategic level more than once we get to the point when we roll out the program, we're going to switch our focus mostly to the operational stewards. So we're going to get these folks involved in the development of the program and architecting the solution and assisting and administering the program and certainly facilitating the data governance council meetings. Somebody has to have the responsibility and typically that's the administrator or the person that has responsibility for data governance within the organization. They participate in the development and delivery of educational materials, they report results to the council. All of these things are the responsibility of that administrator or that group of people that have the responsibility for data governance. So I'm often asked how many people should we have in our data governance office or our data governance team and the best consulting answer that I can give is it depends. It really depends on your organizations. I hear all the time that we need to right size the solution to the organization. My suggestion is don't start out with a team of numerous people on your data governance program team or your data governance office because you're going to constantly be asked what are these people doing. Don't add to your team until you get to a point where there's things that you're going to have these people do. So you can start out small. It can be one person's responsibility and then they can have partners in crime, people that are part of their environment or other people that want to get engaged and start to build out governance that way. But don't start with overkill as far as the number of people that you have on your team. So the data governance administrators play a key role within the program and if you don't have somebody who plays this role, who's doing these things, your program will be at risk immediately. So we need to keep that in mind. What are some of the responsibilities of the partners, the other partners that we're talking about? Well, typically their responsibilities fall under the things that they already do. If IT security is a partner, if risk management is a partner, if project management is a partner, they already have marching orders as to what they need to do and they can help you to make certain that your program moves forward effectively. But they're already doing forms of governance that need to be recognized. So we want to make sure that they're going to be responsible for technical data handling, for securing the infrastructure, all of those types of things. But they're also the subject matter experts when it comes to the technical aspects of the data and the technical aspects of the systems that are using the data. So what are some of the additional responsibilities of the partners? It is to ensure that the policies procedures are in place, ensure that the strategic data is modeled if need be, provide technical support if that's what their role is. You know, the partners do what they do and we should learn to find ways of leveraging what they're doing and we could even use the term governance to describe how what they're presently doing is already related to governing the data within the organization. So one of the last two things that I want to talk about and then we're going to turn it over to Shannon for some questions is who are the people that participate at each level? And it becomes very important for you as you're documenting your roles and responsibilities to provide these three things. So the first part is in the black, that's actually I have the similar role here, data governance council for both, you know, that's the name and that's the level, you know, who is it made up of and how much of their time is going to be expected. So we get expected to be needed when it comes to governing the data. So if we need to suggest, you know, at least recommend all three of these things, same thing holds true for the subject matter experts at the tactical level and the data stewards. Again, these are just examples of what organizations have used to say who makes up the people that are going to be participating at that level and how much of their time is going to be necessary moving forward. So the operational data stewards, they're the folks day to day defining, producing and using data that we're helping to understand what governance is what the role of the steward means and what types of tools and artifacts and things are available to them at the operational level to help them to manage the data better at the operational level. So we know as part of our roles and responsibilities document that we need to not only define, you know, the name of the role with a level of the role, who's going to participate, how much of their time is going to be necessary. And then of course the last thing will be, you know, what are the specific responsibilities that we're going to give to people at this role, specific role within the organization. So here again now shows the data governance working team, which is going to be the last subject I'm going to talk about and putting together these teams that are made up of tactical and operational folks that are focused on solving a problem or at least being engaged to move some aspect of your program forward. And then there's the data governance administrator. Again, we want to say who's it made up of and how much of their time is going to be required moving forward with the program. So ultimately, well before I show you what a page basically looks like from a roles and responsibilities document, let's talk about the responsibilities of the data governance working team and how do we use these working teams to be successful within our organization. So oftentimes these working teams are made up of people at the tactical level or at the strategic level or actually most often at the tactical level on the operational level to solve specific problems. And oftentimes these working teams are convened by the data governance council with assistance from the people that are administering the program. So what do we use working teams to do? Well it really depends on what you're trying to accomplish with your data governance program. Are you looking to improve data definitions and standards, creating a glossary dictionary catalog, are we looking to improve understanding of the data that we're going to create working groups that are focused on specific critical data elements that are shared across the organization. What we're going to call these things, how they're going to be used, how they're defined, what their values are across the organization. You may use the working groups to improve production and collection of data, improve usage and understanding of the data quality. I'm working with the client right now that is creating these business unit working teams to go division by division and educate them on what protecting sensitive information looks like and to understand what level of knowledge do they have about the handling rules associated with how the data is being classified. So we're doing one business unit working team per business unit and this doesn't have too much cross representation of the organization. This is specifically solving a tactical problem within one part of the organization. So this was the page I was alluding to. What you see on the screen now is typically kind of an excerpt of one page from the operating model document. It has the name of the group, the level that the group resides at, who it's made up of, how much of their time is going to be necessary, and then the specific things that are the responsibilities that go along with that specific role. So if we have a page for each of the different roles within our organization, it's going to be very helpful to be able to give people the knowledge as to what is expected of them and how much of their time is going to be necessary as we roll out our program. And the most important aspect of this page basically is who's going to be making up the working team? How much of their time is going to be necessary? We want to make certain that we clarify that and that we give a good estimate as to how much time is going to be necessary so that people have the right expectations going into the development of their program. And this is a diagram that I know is difficult to read, but basically it's a racy diagram. And so whatever the pilot activities or the value add activities are that you have the working team working on, you might define them in a racy matrix where down the left-hand side you have specific steps that are being taken by this working team, and then across the top you have the different roles and responsibilities that we've talked about during the webinar. But then we want to make certain that we articulate what are the specific activities of the working team? When do they get involved? How much of their time is going to be necessary? And what we can ask of them moving forward. So the working teams are starting to play a critical piece because that's really where the rubber hits the road and we start to execute and operationalize data governance within the organization. So I know I've shared a lot of information with you in a very short period of time, but these are the things that I discussed today. I went through the different levels. I talked about some of the things that might be necessary to customize your model to fit your organization. We talked about some detailed responsibilities and who participates at each level. And then last but not least we talked about the working teams and using the working teams to implement the tactical solutions within your organization. So with that, before I turn it back over to Shannon for the Q&A, I just wanted to make you aware of the webinar next month, I'll be talking about building an effective data governance framework. And we'll talk about roles and responsibilities as being one of those core components to a successful data governance framework. And with that, I'm going to turn it over to Shannon to see if we have any questions today. Hi Bob, thank you for another fantastic presentation. And just to answer the most commonly asked questions, just a reminder, I will send a follow-up email by end of day Monday for this webinar with links to the slides and the recording. There was also a request for the matracy, which is also going to be included, so we'll be sure to get that to you. So diving in here, Bob, what is the most basic model or at least amount of roles that can exist to support a data governance system? That's a great question. I don't know if I've ever been asked that before, what kind of is the bare minimum? Well, certainly you're going to have operational data stores, but you're not going to engage them too much. So you might not necessarily need to. I mean, you might actually engage them in teaching them the things that they need to do in order to formalize what they're doing in their job, but we're not going to be asking a whole lot of different things from them. So you might consider very much minimizing the need or what you share around the operational level. I've seen the executive level taken off of the diagram before, too. So seriously, the strategic and the tactical level seem to be the most important. I've seen organizations, again, trying to simplify the model and just using the strategic, the tactical and operational, and not having anything on the support side as well. So at least at a bare minimum, you'd want to have the three levels. And again, identify what already exists within your organization. I hope that answers the question of what can we do to minimize it, but the fact is if a lot of these things already exist in the organization, there might be less of a need to minimize it significantly. So, Bob, we don't distinguish between operational and tactical in our data governance structure. Anyone else in a similar position with regard to data stewards? I have not found it to be successful if you don't have people that are looking at the data across the silos, and that is the tactical level. So you're going to have operational stewards. You already have them. By all means, everybody is a data steward, right? But at the tactical level, where you have people who have responsibility for data across the organization, that's the only way that I've seen organizations able to cut down some of the silos that they have in the organization. If nobody's looking at that data across the organization, then there's a mistake, and that is the tactical level. So I'd say I wouldn't blend the operational and tactical. I'd keep them as they are. Could there be a possibility of conflict of interest between tactical and operational levels with individuals playing in both layers? And how do you address that? There's always going to be conflict, right? That's the reason why we need to be able to escalate issues from the operational level to the tactical and then to the strategic if necessary. There's always going to be issues. If everybody already agreed on the names of what we call things and how they're defined, wouldn't the world be a much merrier place? There's always going to be conflict, and that's why you need to define the operating model in such a way that you can escalate issues up to get them resolved. So that just seems to be a given within most organizations. My organization just launched working groups. The structure of the groups are unclear. So how do you set a structure for the different working groups that have different focuses? Well, typically what you're going to do is you're going to give you as an example the protecting sensitive information example. You know, we have people from risk management and IT security that are just part of the team of working with the business unit working team. So those are partners that are getting involved. The administrator of the program has to be involved. Then we want to make sure that we engage the appropriate tactical level people that have knowledge about or maybe even the authority to make decisions about data in a specific subject area. And then you might want to involve the people at the operational level as well. So there's not one clear structure for how the working teams are made up, but typically you're going to have the administrator. You're going to have some domain stewards. You may engage some operational stewards and potentially some of those other partners that I mentioned. So again, the working teams are the critical component of making this work. So my suggestion is that you include anybody that's going to add value to what it is that you're trying to do with that working team. And what's the typical size of the data governance council? Absolutely. These are great questions. Everybody wants to know about how big some of these things are. Well, the council typically has representation of each of the different business units and IT within the organization. And so if you've got a lot of business units that kind of roll up into a specific functional area or maybe the reverse, maybe just that functional area needs to be represented. I typically find that if you have meetings of more than 10 people, it's a little difficult to manage those meetings. So I guess if you were going to ask for a ballpark figure, I'd say try not to go above 10 or at least make certain that you're engaging only the members of the council that need to be engaged when you're engaging them. If you bring people to the meetings and the things that are being discussed have nothing to do with them, they're going to be, excuse me, less likely to appear at the next meeting because you didn't really need them at the first meeting. So my suggestion is make certain that you have representation across the organization and don't make it too big. I think we have some time for additional questions coming in just a couple more. But if you have questions, Bob will always keep them coming in whether we have a chance to get to them today in this webinar or not. Bob will write up answers and we'll also include that in the follow-up email. So Bob, do you think it is a bad practice for an organization to set a policy that only managers or above can service data stewards? Only managers and above? Well, if the managers and above are the only people in the organization that are using data, by all means go ahead and do that. The fact is that it's not just the managers, it's the people that are day to day performing the business functions that are the actual stewards of the data. And so if you have an organization that's so large that you're going to actually refer to the operational data stewards as being managers, at some point you're going to need to then have a more operational level that would be people that are not managers, because you want to impact the behavior of everybody in the organization, not just the handful of people that you're going to engage. I don't like the idea of the operational level consisting of managers unless they also then have the responsibility for all the people that work for them to make certain that they understand their responsibilities as well. So I would vote no for the data stewards only being managers and above, but it really depends on how your organization is structured. I can't give you a blanket no to that, but I would say I most likely not to have managers as your operational data stewards. So categorize as data governance as part of IT governance. What are your thoughts on how the two work together? Well, I haven't really seen data governance as part of IT governance. I guess it could be. IT governance often has to do with more of the infrastructure and the project planning and the system development and those types of things. I typically don't see data governance falling under IT governance. However, I do see it's not really even emerging anymore. It seems to already be here, the whole concept of information governance that could take into consideration structure, unstructured data. I don't think the data governance and IT governance are really the same thing, but I think that the IT governance is a real thing that needs to be implemented. It's just, I guess they could learn from some of the things we're doing with data governance, but some of the activities of IT are different than the activities of the data governance group. And I think we can slip in maybe just one more quick question. We have a little less than a minute. Any experience or reference of applying design thinking and value proposition design to the process of creation and maturity of a data governance government and its processes? Seriously, I get less than a minute to answer that question of all the questions. It can't be. So the value proposition is really important. And I'm going to share this with you because again there's a recent TDAN article that I wrote about this, but the idea is that we really need to get our senior leadership to stop asking data governance necessary. And why do we need data governance? We really need to get them engaged in asking the question, how is it going to get done? And if we can do that, if we can move them from understanding that it's necessary to, what's the best tactical way to implement it? That's when you're able to bring into them what the value is that comes to the organization, but they're more interested in how are we going to engage people day to day so that we can be successful in formalizing how we're managing and governing the data across the organization. Great question. I'll try to pick it up in the written answers as well. Alrighty, well that does bring us to the top of the hour. Thank you Bob for another great presentation and thanks to our attendees for being so engaged in everything that we do. You know we do have, if I didn't get a chance to get to your question, please just keep submitting them. We will have Bob write up the answers which will be included in the follow-up email that I will send out to all registrants by end of day with links to the slides, the recording, the matrices, and again answers to the questions we didn't have a chance to get to today. So thank you everybody and hope to see you in the next webinar. Thanks Bob. Thanks everybody, have a great day.