 And here we go. 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 utilized governance working teams to improve data quality. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the 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 if you'd like to engage more with Bob and continue the conversations after the webinar, you can go to the Dativersity Community at community.dativersity.net. As always, we will send a follow-up email within two business days containing links to the slides, a recording of the session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for this series, Bob Siner. Bob is the President and Principal of KIK Consulting and Educational Services and the publisher of the data administration newsletter, T-Dan.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 would give the floor to Bob to get today's webinar started. Hello and welcome. Hi, Shannon. Hi, everybody. Thank you for participating in the webinar today. I always appreciate your taking some moments out of your busy work days to attend these webinars. Today, we'll be talking about utilizing governance working teams to improve data quality. It seems to be a very timely subject for a lot of organizations who are looking to operationalize their data governance programs. So we've got a lot of materials to go through today. So let's get it to get moving here. Before I get started, I'd like to quickly touch on a couple of the other activities that are going on in the data governance space and the data quality space. And a lot of them have to do with data versities. So first of all, just to remind you that this is the eighth year that we've been doing the real world data governance series. And we've started planning for 2020. And so even though it says January 16, 2019 on the screen, it's actually January 16, 2020 will be the first webinar of the new year. And we'll be talking about a subject very dear and dear to me, non-invasive metadata governance. As we all know, the metadata will not govern itself. Let's talk about getting people to govern and be stewards of the metadata as well. I talk a lot about non-invasive data governance. If you're interested in learning more, please check out the book called Non-Invasive Data Governance. I'll be speaking at a few upcoming data versity events. One that I'm real excited about is coming up in January. That's the online, the virtual conference that takes place every year. And we had lots of people on it last year. Hopefully you'll join this year. It's a great event. I'll also be speaking at Enterprise Data World in San Diego coming up in March. There's a couple of online sets of courses that you can acquire through data versity, one on non-invasive data governance, and one on the topic of the January webinar, which is non-invasive metadata governance. And then there's the data administration newsletter, my online publication. Please check it out. It's free. Lots of great articles and lots of great content on data governance and other data subjects. And last but not least, KIK Consulting. KIK stands for Knowledge is King. The focus of my practice is on non-invasive data governance and metadata governance. So let's spend a little bit of time here talking about what we're going to address in this webinar today. These are the subjects that we're going to walk through. We're going to, first of all, talk about when does it make sense to utilize working teams within the organization. We'll talk about how to construct a working team based on the purpose of what you're trying to accomplish with your working team. We'll talk about differences between working teams and communities of practice or communities of interest. We'll talk about monitoring and reporting on the status of working teams and what they are accomplishing in their activities. And then last, we'll spend a little bit of time talking about how to deliver successful and repeatable problem-solving teams within our organization. But before I get started, let's just touch on a few definitions and get everybody on the same page as to how I define data governance and data stewardship. I define data governance very strongly. In fact, it makes some people sit up and sit forward in their chair when they see that I say data governance is the execution and enforcement of authority over the management of data. Those are strongly worded terms, but the idea is that no matter how we're approaching data governance, we need to execute and enforce authority. However, we're defining authority for data within our organization, and data stewardship is the formalization of that accountability. So recognizing that there are people in the organization that already have a relationship to data and formalizing that accountability as definers, producers, and users of data across the organization is what data stewardship is really all about, especially if we're going to take the non-invasive approach to data governance. And basically a data steward can be anybody in the organization, or as I've been known to say, it can be everybody in the organization if they're being held formally accountable for the relationship that they have to the data. That's as a person who's defining data for the organization, producing data, or using data. So I think it's good to kind of start off with some definitions so that we're all on the same page as to what governance is, and then we'll talk about how the working teams can focus on improving quality. The last definition I want to share with you is non-invasive data governance, and that's really the practice of applying governance to what already exists within your organization. Seeking out who the people are that define, produce, and use data, and applying some level of formal accountability for their relationship to the data, and applying governance to existing process rather than redefining everything as a new process. So non-invasive data governance, really the goal of it is to be transparent, supportive, and collaborative, and non-invasive doesn't describe the outcome, it just describes how we're going to apply data governance within our organization. The first subject focused on working teams today that I want to talk about is when to make use of working teams within your organization. And let's make certain that we're aligning these working teams with the purpose of what we are trying to achieve through our data governance program. And I'm listing five different purposes that organizations have selected to achieve these outcomes from their data governance program. You may have others, but these are some of the ones that I see being used most consistently across the organizations that I've been in contact with. And the first one is to improve the quality of the data, and then to improve the access to data and how quickly we can get access to data and giving the access to data that really need it, giving the people access to data that really need it, and making certain that we have rules associated with who gets access to data and what data they get access to. Another reason that organizations put these teams together is to improve the understanding of the data. And I'll share an example with you of an organization that actually created working teams to develop data catalogs and business glossaries and data dictionaries. So certainly that's not going to happen on its own. We need to create these teams of people that have the responsibility for putting these things together for the organization. You know, another purpose may be improving interoperability, and certainly one that we're all aware of is the protection of sensitive data within our organization. So when we put teams together, you know, what are some of the things that we need to consider, again, depending on the focus of our program. So the first focus that I spoke about was the quality of the data, and you'll notice that the first bullet under each of these improvements is the same. And that's critical. In fact, that's going to be the second section of things that I talk about in this webinar is how do we identify and recognize the appropriate people to engage on these working teams. We're going to need to convene working groups basically made up of stakeholders and SMEs, subject matter experts, stewards and partners of us within the organization. So what are the steps that we need to take to make certain that we're engaging the appropriate people in the activities of the working team. A lot of organizations focus on creating these working teams to solve quality issues. So oftentimes they talk about creating incidents or at least documenting incidents and creating teams to address those incidents or those issues. And what I'd like you to consider is that there's another spin that we can put on that, which is, let's have them address opportunities. So not only the negative of data quality issues and data quality incidents, but if we can be looking at ways to utilize our working teams to address opportunities to further the education and the understanding and the knowledge and the shareability of certain data across the organization. These are opportunities for us to improve. So yes, it's still kind of, it can be reactive, but in a lot of ways it's also proactive where we're saying, you know what, if we improved our understanding of data around, for example, customer loyalty, that would be an opportunity to add value to the organization. So it doesn't always have to be a data quality problem. It can be an opportunity that's going to add value to the organization as well. In order to do this, you know, a lot of organizations, when they set up their programs initially, they identify a pilot or at least an initial incident that they want to focus on in the organization. In order to sustain a data governance program, it really requires that we have an intake process, that we have a way of being able to bring new opportunities, bring new issues to the table. So one of the things that we need to consider if we're developing working teams to focus specifically on the quality of data is, well, what happens after we address the pilot? Do we have a way to line up and kind of queue up different opportunities and different issues that we're going to address? So that's one of the things that I suggest to a lot of organizations as they're creating these working teams to address issues. What are they going to do next? What's coming down the pipeline? So making certain that you set up a process to intake different incidents, to intake issues and intake opportunities is a way to sustain and keep your program going on an ongoing basis. And in fact, when you're talking about operationalizing your program, you really need to have an intake process in place. Who's going to submit the issues and the incidents? Who are they going to submit them to? How are they going to submit them? Who's going to prioritize the issues? Those are all parts of that intake process as we start looking for additional opportunities for data governance to help in the organization. A lot of organizations, when they're setting up their quality teams, their data governance working teams to focus on quality, focus on what is now being called critical data elements. And you may see that term being used across the industry now where critical data elements or CDEs has become a regular subject of conversation. When we're talking about critical data elements in a lot of organizations, that is the strategic data that is going to add value to the organization. So when we're creating working teams to focus on quality data, a lot of the times that specific data that we're working on improving the quality of can be referred to as critical data elements or CDEs. So understanding what data is critical in the organization is very important and having a method to be able then to address the issues and the opportunities associated with those CDEs is also very important. So a lot of times when we set up our program, excuse me, we set it up, we define specific roles and responsibilities, communications that we're going to provide for the organization based on what governance is setting out to accomplish and the status of what it is we are accomplishing. You know, oftentimes when we define those roles at the beginning, we don't really know if they're going to work or not for the organization until we start to create these working teams and make certain that the roles that we've defined are working when we start to operationalize data governance. And one thing that we should not be afraid of is changing how we've defined our roles. If we've defined our roles right out of the gate and we find out that they're not working for the organization, we should have the idea that we'll adjust the roles to make sense to function properly within our organization and we'll adjust our communications based on the results that we're getting from that communication. Some organizations will set up working teams to focus on access to data. And again, the first bullet point under improving access to data is convening the right people, getting the right people into the group. And oftentimes that helps us to make certain that we're recognizing who has the responsibility to make the decisions as to who gets access to the data. If you can recall from other webinars that I've given when I talk about data domain stewards or subject matter experts, if those are the people that have the responsibility for being able to grant access to data or have the authority to be able to say that this data can be shared with X, Y, and Z, you know, we need to make certain that we document who those people are. Those people play a key role in our governance program, specifically when it comes to the tactical roles and responsibilities that we've defined as part of our program. We need to have a group that defines what the rules are going to be for accessing the data. So instead of just leaving it on one person to say, yes or no, this person can have access or can't have access to data, we need to make certain that we've defined and we've gained approval for the rules that define who should have access to what data. And oftentimes if those rules are not created, it makes sense to create a working team, you know, focusing on the quality of the data, but focusing on the quality of the access to the data. And oftentimes we'll find working teams that are set up to do that, to define and approve the rules that define who gets access to the data and how they get access to the data. We also need a process for making certain that people can gain access, but then if they're denied access to the data, there also needs to be a governed process for them to be able to address that denial and make certain that the denial is appropriate or to make certain that these people do get access to the data that they need to get access to. So in order to do that, one of the things that we need to do is to record who does what with the data across the organization. And I oftentimes share a common data matrix, which I'll share with you in a couple of slides. It's a simple two-dimensional spreadsheet that you can use to record who does what with the data so that when it comes to giving people access to the data, we need to know who gets access, how they get access. We need to document that they have access to the data, and all of that information can be collected within the common data matrix. Like I said, I'm going to share that with you in a couple of minutes here, but it's a really useful tool for us to really understand who does what with data across the organization. I mentioned before that I was working with an organization recently that convened working groups to make certain that they had a data dictionary and a business glossary for the data within the organization. In fact, they created two different working teams. One to focus on the semantics of the data and the language that's being used by the organization. And the second working team was focused on defining the data dictionary for information that was in their data lake and in their data warehouse. So they were convening teams to help improve the understanding of data across the organization. And they created these teams again to focus on the semantics and the business descriptions of the data before we actually got to the point where they started documenting attribute by attribute element by element. What do the different pieces of data within the data warehouse in the data lake? What do they really mean? And you know what the fact is that in a lot of organizations and your organization might be one of those that there needs to be an improvement in the understanding of data. We need people to understand that data that is named in different ways may have the same meaning or the data that has the same name might have a different meaning depending on the context of that data. So the first thing that we need to do is make certain that we get the appropriate people involved in the development of these working teams. You know, whether they're stakeholders and SMEs, whether it's the stewards and the partners, the fact is that if we're looking to improve the understanding of data across the organization, that's not going to happen on its own. The metadata associated with these working teams, the metadata that's being created by parts of these working teams are not going to govern itself. Somebody has to have the responsibility for collecting that information. Somebody has to have responsibility for validating and certifying that information and making that information available to all the users of the organization that will benefit from improved understanding of the data. You know, I say this a lot. I say that the data won't govern itself. I say the metadata won't govern itself. The fact is in order to achieve everything that we're trying to achieve with data governance, we need to have people with responsibilities for making certain that this happens. The data governance working teams are one manner to go ahead and start improving in these different areas. So as I said, you can create a working team to develop your data catalog, your repository of an inventory of systems and data and sources of structured and unstructured data in the organization. You can build out teams to create business glossaries and data dictionaries. Ideally, it's not going to be an IT event. It's going to be a combined effort between IT and business. So we want to make certain that we're engaging the business in the development of these different tools. And by these tools, I mean the catalogs, the glossaries and the dictionaries. And one way to engage the business is through the development of these working teams. And what we need to do is evaluate and adjust the access to the understanding. Make certain that the people who need access to the documentation, the metadata, the understanding of the data that they have access to it. And talk to them about what's the best way that you can deliver that understanding of the data to the people that are using the data. Other organizations are focused on developing these working teams or convening working teams to focus on interoperability or shareability of data across the organization. We often find that it's difficult to combine data from one data resource with another data resource because the data doesn't align properly. The data that we're looking to combine the data and integrate the data on has different definitions, has different attributes. Now, we need to make certain that we can improve the way that we share data across the organization. And oftentimes groups that are convened to focus on interoperability issues look at exactly that. They're looking at those specific pieces of data that are necessary for us to be able to combine data, pool data together. You know, we find a lot of times that the data scientists within the organization are spending a lot of their time pooling the data together and less of their time actually analyzing the data and do the things that data scientists are most skilled at. If we can reduce that amount of time by making certain that the data does match up across data resources, we'll find that we'll be able to improve the ability to share data across business systems, across business areas of the organization. And one term that I keep hearing over and over again within organizations is the idea of digital transformation. If your organization is moving in that direction where it's really becoming all about the data, you're becoming a data-centric organization, it's going to be very important for you to be able to combine and share and, you know, use multiple data sources in order to solve problems. And if we can prepare the data in such a way that the data analysts, the data scientists don't need to spend that time manipulating the data, that's going to help our organization significantly. You know, we're paying these people good money for the data scientists' science knowledge, for their analytical knowledge. And, you know, if we can improve the documentation and the information that they need about the data and we can improve on those specific pieces of data that are going to improve our interoperability, that's an excellent use of a working team within your organization. So oftentimes we're looking to how are we going to solve some of these problems? Working teams may be the answer to that question. And again, the working teams are not necessarily set up for a long-term basis. They're typically created to solve specific problems in specific periods of time. And the last example of the use of a working team that I want to share with you is to focus on the protection of sensitive data. We know with the New California Protection Act and with GDPR and all the other privacy legislation that is either being handed to us now or that's coming down the pike, we need to make certain that we're protecting sensitive data. So again, pull together the people from risk management, from IT security, from communications, from governance, to make certain that we're getting the right people into the room to just start talking about how are we going to assure to our auditors and to our examiners that we are protecting sensitive data. So we can convene working teams to be able to do that. And what are some of the things that that working team might focus on? Well, it might be focusing on defining what your classification rules are. What is considered to be confidential? What's considered to be sensitive or public or open data? So certainly if those aren't already defined or they're not already communicated effectively across the organization, that could be the use of a working team. And once we've defined the classification rules and we have them approved and perhaps we even create a policy associated with how the data is classified, we need to be very clear as to what are the handling specifications that go along with each of those classifications? How do we handle data that's confidential in a way that's different from open data or public data within our organization? In fact, one of the things that we need to recognize is that as data goes through its lifecycle in the organization, that classification may change. You know, up to a certain point, it might be confidential data. But then at a certain point when it's released to the public, the classification has changed and therefore the handling rules have changed. And when organizations are defining the handling rules, oftentimes they break it into at least two categories. And those categories would be what do we do with data at rest? Data that's stored in databases that's stored in repositories. And then what do we do with the data in motion? Do we need to encrypt data that is considered to be confidential? Do we need to use sensitive or encrypted jump drives or personal devices as we're moving data from one place to another? So convening a working team of people focused on protection of sensitive data is extremely important. And especially in this day and age where privacy seems to be all the rage, you know, we need to focus on making certain that we have an honorable way of being able to demonstrate that we are protecting sensitive data. By convening a working team to do that, now you've given them the responsibility of make certain that a classification rules are appropriate. Make certain that we have policy associated with protecting sensitive data. And that we've defined what the classification means when it comes to what you can do with the data in the organization. So now we've talked about some reasons for creating a working team. I want to spend a little bit of time talking about who the participants should be on the working team. The first role that I identify here is the data governance administrator or the data governance office. And the reason that I do that is that somebody needs to have the responsibility of pulling the team together, of defining the steps of the process that are going to be followed by the working team. By making certain that the people are actively engaged in the different steps of the process. So you need a data governance administrator or a data governance office or at least somebody that has the responsibility of guiding the working team. Now other people that we need to involve on it would be the subject matter experts and the representatives of the business areas of the organization that are being impacted by whatever it is that the working team is working on. We want to make certain that we don't try to do this with our hands tied but with one arm tied behind our back. We want to bring information technology and project management into the fold because ultimately what you work on with your working team might turn into a project or it will turn into a project if it's going to require changes within the organization. So we're going to want to engage information technology and we're also going to want to make certain that whoever is sponsoring the activity is being engaged. So let's start by talking about the data governance administrator and if you've heard me talk about data governance best practices before the very first best practice that I talk about is that senior leadership should support sponsor and understand what it is we're doing with data governance. The second best practice is that somebody has to have the responsibility for guiding the ship and leading the way and that's really where the data governance administrator plays a very key role in these working teams that are focusing on, you know, addressing specific issues within your organization. So first of all, if you're starting a data governance program since that is best practice, when we're defining our roles and responsibilities, we need to make certain that we've defined clearly the role of the data governance administrator or the data governance office. And oftentimes they're the people that will facilitate the activities of the working team. Now oftentimes these working teams result in the creation of racy matrices. If you know what I mean by those, you know, who is responsible who's accountable, who's consulted and who's informed along each step of the process. And oftentimes again it's the administrator that has the responsibility for making step making certain that those steps are being followed. But one thing that I found in a lot of the racy matrices that have been developed over the years is that the data governance administrator or the data governance office is actually responsible for each step or responsible for getting the most the most appropriate people involved in the steps. So as I said before, the data will not govern itself, the working teams will not guide themselves. We need to have somebody from data governance administration involved in those working teams. The one that's really a no brainer is the subject matter experts or the quote unquote data owners, the people that own data or own applications across the organization. So when you're creating a working team, not only is it important to have that administrator, but it's also very important to have the subject matter experts, the people that are in the know, involved in those meetings. So we're going to look for people who need that are the reason why we are convening these working teams. So we're going to look for the person or the people who need the opportunity to be addressed. And I said, as I said before, I'm going to talk about the common data matrix. I'm going to share a version of that in a couple of minutes that shows how can we start to recognize who the appropriate people are that we should engage in these working teams. And oftentimes the subject matter experts when I said that the data governance administrator has the responsibility is responsible for many of the steps. Oftentimes the subject matter experts or the people that we're doing these activities for are also responsible. So it's kind of a co leadership in each of the different steps of a racy matrix. And, you know, a lot of organizations will look at their needs to be at least one person where there should be only one person or one position that's accountable for the steps of the process. There could be people that have shared responsibility for those steps in a typical racy matrix. So we want to make certain that we were involving the critical decision makers, the people in the know the subject matter experts, and oftentimes those are people at the tactical level of the organization. There are people that are looking at data across business units, rather than just specifically within a single business unit. We certainly want to engage representatives of the areas of the organization that are being impacted by whatever change is coming down, according to the work that's being done by the working team. So we need to do we need to identify who's going to be impacted. And if we can do that impact analysis and we can see which parts of the organization need to be engaged, we need to pull at least representatives of those areas into the working team. And again, when I share the common data matrix with you, you'll see that it will become really obvious if we're focusing on specific critical data elements that there are specific people within the organization that we want to create on these teams, or we want to include on these teams. Now, I don't want you to get the idea that these teams have to be made out of massive numbers of people. Typically, there's a finite number of people. You know, we might want to make certain that we inform a lot of these folks as to the activities of the working team, but the ones that are actually rolling up their sleeves and getting active are typically a finite number of people. You want to make certain that it's manageable and that you're engaging those people that you have as part of the working team, the people that are allocating their time to the working team, they need to know that there's value coming from the time that they're committing to these opportunities. And so when we get these people involved, you know, I actually heard another consultant say, you know, if people don't want to get engaged in these working teams, all we really need to say to them is, okay, well, we'll solve the problem and we'll come back to you with a solution. And oftentimes they'll step up and say, wait, you can't do that. I need to be involved in this effort. So they'll want to become engaged now. So it becomes kind of a pay me now or pay me later proposition where we need to get them engaged as early as possible. And as I said, working without IT and project management on your working team is like working with one hand tied behind your back. You need to have technical resource management. You need to know when the technical part of the organization or information technology is going to need to be involved. You need these working teams to be prioritized like projects, right? So we have the different opportunities and incidents that we're going to address. And somebody needs to be telling us which are the most important opportunities that we should address first. We need to prioritize those. And oftentimes we need a project manager to make certain that any technical changes that are going to need to be required by the working team can be addressed across the organization. So defining the technical requirements and the capabilities, basically the result of most working team activities is an IT project. It's going to be something, okay, we've defined that we need to make some changes to systems or we need to change the access rules or we need to change the classification of the data. Oftentimes that becomes a project. So if we construct a working team without members of IT, without some project management involved in it, that's a mistake. We need to include IT's knowledge and we need somebody to kind of steer the ship when it comes to the projects. We need representation from the activity sponsor. You know, these are the people that want to make certain that these problems are being solved. So we can include people from legal if necessary, audit for certain, you know, HR if it's going to impact people in their job, and certainly communications. We want to make certain that the outcome of the working team is going to be communicated effectively across the organization. So we might want to look at the different data governance partners that we have and involve them when needed in the activities of the working team. Now, I mentioned the racing matrix before, and this is just an example. I don't have a blown up version of this, but you get the idea that down the left hand side of the matrix, we have the different steps of an act that are the actions of a specific working team. In this example, I'm calling it ACME data governance as ACME is the company, but they're focusing on critical data elements associated with a specific subject matter data. So identifying the team is one of the first steps, but we have all the different roles and responsibilities to find across the top of the matrix, and all the steps identified down the left hand side. And so what we want to do is make certain that we have defined who is accountable, who's responsible, who's consulted, and who's informed across each step. So once we've identified the teams and we've identified the actions that are associated with the working team, and we want to make certain that we are very clear on who's responsible, who's accountable, all of these different things as we start the activities of the working team. Now, I mentioned the common data matrix a couple of times, and this is my eye test. I'm going to give you a blown up version of this, but I call this the common data matrix. And it's a way of us documenting and recording who does what with data across the organization. So let me share with you a blown up version of this. And this is from the higher ed field or higher ed industry university where they decided to focus their working team on space data. And by space data, they meant site data and building data and room data and floor data. There's a lot of different pieces of data that are associated with each of those sub domains of the space domain. And some of those pieces of data might be identified as being critical data elements. So what we're doing is we're going from less granular to more granular as we work from left to right. And we go from domain to sub domain down to the specific critical data elements indicating whether or not those are critical to the organization or if those are identified as being strategic data. And if we continue to work our way across the matrix, we can see, well, where is that data stored and who in it has the knowledge about that specific data in that specific system. But if there's one thing that I want you to take away from this webinar today, it is the need for having a tool like this, whether you use a common data matrix or something else, we need to know who does what with data across the organization. And the common data matrix becomes a really excellent tool for doing that. And now here's a kind of a backed out version of the common data matrix. We can then say not only from the IT area, but from the different business units of the organization. And some of those business units can be broken into some business units. Where do they get their data from? You know, we get senior leadership asking the same questions of multiple people and getting different answers. And why does that happen? It happens because day people access the data from different places within the organization. And we need to know that we need to be able to demonstrate to them the reason why you're getting this this answer from these people is that they're accessing data from these systems. And the reason why this other answer is different is because they're going to different systems or they have different understanding of the data. All right, we're going to need to move quickly here. Let's talk about the differences between what we're calling working teams in these communities of interest. And the difference that the primary difference is that the working teams are very specific and the communities of interest are more general. So let me walk through some of the aspects of working teams versus communities of interest. So in the working teams, you might focus on a specific set of critical data elements. So it's a specific opportunity or incident or issue that they're focusing on in a community or a community of interest. It could be the same general interest senior organizations create customer data quality communities of interest. And that's bringing together people that are interested in improving the quality of the data within a specific domain or subdomain of the organization. The working teams are focusing on improving the quality, improving the understanding of specific data, perhaps within that same domain or subdomain. You know, the working teams are facilitated into action. The communities as Shannon has talked about the communities within diversity. These are areas where people can network people who have ideas around improving the quality or improving the value of something specific within the organization. That's where communities of interest are created. The working teams typically have a beginning and an end. They're convened for a finite period of time when oftentimes the communities that are being created are created for longer periods of time. They're a community of interest that's going to be around, you know, over a stretch of months or years rather than a specific set of people that are brought together to solve a specific issue. So let's look at the differences between the processes of a working team versus a community of interest. The working teams are going to focus on some of those things that I mentioned earlier in the presentation. The quality of the data, the understanding, the access, you know, focusing on critical data elements or the protection of the data when the communities of interest are more interested in focusing on networking and education and bringing people together that have the same common interests in the organization and communicating effectively with them. So again, working teams are focused on specific problems. Communities of interest are more brought together to share ideas, share tips and techniques that are going to be of value to people across the organization. Let's talk about the administration of the working team versus the community of interest. Well, typically the working team, they're responsible for taking care of all the steps that were included in the race. And oftentimes it's the administrator with the assistance from some of the subject matter experts that are actually responsible for each step of the actions. And the data governance administration or data governance office has the responsibility of facilitating those actions and making certain that communications are being provided to management and that somebody is measuring the value of the actions of the working team versus the community of interest, where there may be a community coordinator, or we're going to convene this community of interest based on, you know, what are people or what are they caring about? Is it a specific set of data or is it something that a specific process? Is it a specific subject area rather than a specific problem? Oftentimes these are user interest driven, and people are encouraged to participate, but they're not being told that they have to participate. Oftentimes when you're creating the working teams, we're creating a team that has a specific goal in mind, and people have specific responsibilities within those teams. When it comes to the communities of interest, it might be less so. It might be more of a networking opportunity in a way of sharing ideas associated with the data. Let's talk about engaging a team versus a community. So oftentimes when you're creating a working team, you're going to need to identify what resources are going to be required. Who's going to be accountable for doing what? It's very process driven because you're looking at a business outcome from the working team and less so when it comes to the community of interest. There's typically not resources required. There's not necessarily resources that are accountable. It's very socialization based and sharing ideas across the organization. And the status of what's happening within the communities are used to sell participation in other communities. It may be used to sell participation in the working teams themselves. So we want to make certain that we're communicating the results of the communities as well, or people will stop wanting to be participating in those communities. So again, working teams, very specific communities of interest less so, but they can also be vital within an organization. And when we're communicating with each of them, the working teams and the communities of interest, we need to orient people to what we're doing as they get involved in either the working teams or the communities of interest. They need to be onboarded and let them know what's expected of them and what they can expect from participating in the working team and the community of interest. And then there's ongoing communication. You know, the status of what is happening within the team or within the community. And, you know, that in the metrics that show, you know, what benefit has we brought, what value have we brought to the organization. So we need to make certain that we're focusing on communicating with both the working teams and the communities of interest. Let's spend a little bit of time talking about monitoring and reporting on working team status. So we need to evaluate and demonstrate the values of the teams. And oftentimes that can be displayed demonstrated through the use of a pilot. So we convene a working team as a pilot activity and we see how well it works for us. Well, we're going to need to be able to quantify the results of the team. We're going to need to be able to provide ongoing communication to the team. We're going to want to make certain that those individuals at the strategic level are being communicated with and being reported to the status of the activities of the team. And we certainly want to sell and take advantage of any successes that are being demonstrated by the team so that we can kind of duplicate that or replicate that in additional teams that we're creating moving forward. So when it comes to quantifying the results, you know, we can start to count the numbers of opportunities that we're addressing, the number of incidents and data issues that are being recorded. But it's only one piece to start to share with people what has been reported. We want to let people know how many of those issues or incidents or opportunities have been prioritized and how many of them are being addressed. So when we're quantifying the results of the team, we need to look at, well, what are the teams focusing on? You know, how has it been prioritized? And what has been done to address the issues for the reason why the working team was set up? We want to make sure that we can ensure that there's value in addressing the opportunities that we're engaging the appropriate people. And if we find that certain people that we've defined as part of the team aren't engaged, we should look at how can we get them engaged? Or if they are not engaged, maybe we don't necessarily need them as an active participant on the working team. So we want to make certain that as we're creating these working teams, we're trying to create efficiency and effectiveness in what we're doing. So we want to focus on the speed of the ability of the team to be able to address the opportunity. And we want to reuse the efforts to address other opportunities. I spoke a lot about, you know, creating kind of a toolkit of processes that our data governance working teams have focused on. And then when we get an incident that comes down the pike that looks a lot like another incident or another opportunity, we can reuse the process. Reuse the way that we convened the working team to address the opportunity. So the goal of the organization is often to create repeatable processes. And I've had clients that have been talking about things and I'll address in a second data governance as a service or data governance as a product. Well, what are those services? What are those products? You know, those are the things that we can repeat. If we've taken a set of critical data elements and we've improved the quality and the understanding of that data and somebody catches wind that you've done that. Well, they say, well, maybe you can do that for us as well. So let's dig back into our bag of tricks or should I say our repository of repeatable processes and identify what we can reuse to the benefit of other people in the organization. So we need to communicate this on an ongoing basis. And we need to let people know where we've added value through the use of these working teams so that other people can look for additional opportunities and incidents and issues that we can create working teams to address. Somebody has to have the responsibility of reporting the results of the working team to the council. So that could be the number of opportunities and incidents, but also getting them involved in the prioritization of what's most important to the organization and making certain that if these things turn into projects that there's resources that will be provided. It's great to say, well, we can solve the problem if we do X, Y and Z. But if we don't have the people and the resources set up to be able to help us to get to that end, it's a useless battle. You know, because we need to have resources at some point in time where the actions of the working team actually become addressable. And if we're going to need to engage these people, there needs to be certain that there's resources available to address the issues. But we want to make sure that we report to the data governance council the status of the opportunities that are being recorded and addressed. We want to let them know what artifacts have we created as part of this process that we can then reuse in other situations across the organization. We can also communicate to them the metrics and measurements of success and any messages that we can share with them that they can share with executive leadership. And as I said, the very first best practice is that your senior leadership supports sponsors and understands the activities of data governance. Well, if those activities become the use of working teams to address opportunities and incidents and we're communicating that to the data governance council. We want to make certain that the council feels appropriate in sharing the successes and the issues that we're having with executive leadership. Particularly the data governance council resides at the strategic level, but there's oftentimes an executive level as well. So getting other parts of the organization to make it clear and make it understandable that that these data, these working teams have provided value having customer testimonial from within your organization is really important. So that they can say, well, we did this for them. And we can or you can say that we did this for them. We could do this for you. That becomes a really big selling point, especially if it's not us telling people the value. It's actually somebody that has seen the business value and the business outcomes from what we're doing, you know, saying that, you know what they did this for us. They can do this for you as well. Let's line up a purpose. Let's line up a working team to address those issues. And I spoke briefly about having that bag of tricks, that repository of repeatable processes, and oftentimes we create those repeatable processes through the convening of the working teams and making certain that the steps that we're defining are appropriate. The people that were engaging are appropriate so that when we get a similar issue, we can reach back into that bag of tricks and pull out the process and say, you know, this is the process that we have defined to address the specific opportunity. As we said, we did this for them. We can do this for you. We now have a repeatable process repository that we can go to. And that's really if we're building out data governance as a product or a service, you know, it's really going to be required to have that level of documentation as to what we can do, what we have done and what we can do for other parts of the organization. And to certainly leverage the lessons learned to improve on the roles and responsibilities you've defined and make sure that communications is taking place. Oftentimes, the initial communications is improved upon when we convene our next working team. And then we improve on it again as we convene our next working team. New communications just is something that can improve and improve over time. I mentioned earlier, you know, formalizing an intake process. And let's make certain that either everyone in the organization has the ability to submit opportunities or to submit issues, or that it's just a defined group. In an organization I'm working with now, they've taken their counsel, and it said, let's make it a responsibility of people on the council to define what's strategic data and what data we need to focus on with part with the use of these working teams to improve the quality and the value, the understanding of that specific data. So make certain that you know that people know that they can submit opportunities or define a specific part of the organization where those opportunities come from. And formalize the process, as I mentioned before, to record and submit opportunities, create a method and rubric to help the people at the appropriate level of the organization to evaluate and prioritize the opportunities. And look at the way, how are we going to address this? Is this something that we can address in a central manner, or does it need to be in a federated manner? And by federated manner, I mean, let's define something that we can set up a set of repeatable standards or minimal standards that are shared across the organization. So a lot of what we're doing in using these teams really depends on how we are addressing data governance across the organization. So the last subject that I want to touch with you in the last few minutes is the maturity improvement. It really requires that ability to be able to repeat the success or repeat the actions of the working team. So we want to have repeatable team building. We want to have that repository of the processes and things that we've documented. We want to look at data governance as a product and service. We want to engage stewards to drive these teams. And as I mentioned before, the teams don't typically operate very well if there's not somebody in the organization that has responsibility for guiding the activities of the team. So repeatable team building, again, based on a dependable operating model of roles and responsibilities, I'll be talking about a complete set of roles and responsibilities for data governance at Enterprise Data World in March. And I want to make certain that you have to have the leadership of somebody. And oftentimes the leadership of these teams is at the administrator level or at the data governance office level. We need to know who's responsible, accountable, consulted and informed, you know, create the common data matrix as a way to help us to identify what the critical pieces of data are and where they reside in the organization. We need to learn from what we've done. So when we define a process for the pilot, let's not be afraid to change that process if that process is not working as effectively as we'd like it to work for us. You know, get a repository of the different processes, as I mentioned before, whether they're data quality processes or improving the understanding of the data or getting access and shareability of data, interoperability and integration of data across the organization, or data protection. Now, this is the repository that I'm talking about. If we have processes that we can repeat to address issues that fall into these categories, we can successfully go to people in the organization and say, these are the services, these are the products, these are the things that we can provide to you. And specifically, as I mentioned before, we need to have a process to intake additional opportunities. And we want to base everything that we're doing on reusable roles, reusable processes, again, in that repository and reusable communications. Now, I mentioned data governance as a product, data governance as a service. If that's what we're trying to achieve with data governance in the organization, creating these repeatable sets of services become vital. In being able to say, you know, we've done this successfully for this part of the organization, we can do something similar for you, but we need to have those processes set up so that we can, again, dig back into that repository. These are the things that data governance can provide to the organization. And oftentimes, those are our results of the activities of working teams getting together. So engage your stewards to drive your teams, use your common data matrix to identify the right people at the tactical level, at the operational level. Again, as I mentioned, it's critical to have the administrator or the office involved in the process and keep track of who your stewards are. Use something like a common data matrix or a data governance tool to keep track of who your stewards are. You know, make certain that you engage the governance administration in the activities. They're going to be the ones that drive the teams. They're the ones that are basically from beginning to end going to have the responsibility for not only then taking the prioritized opportunities all the way through the delivery of the business outcome from the use of the working teams. So as I mentioned earlier, I said the metadata will not govern itself. The data is not going to govern itself. Somebody has to have the responsibility of engaging the working team and making certain that they're in line. So what did I talk about today? I talked about when does it make sense to use working teams? How do we construct these teams? How are they different from the communities of interest? You know, what do we need to monitor and report based on the working team status? And we spent a little bit of time talking about how to deliver repeatable problem solving teams to the organization. And I know it took up a lot of time here, but I'm going to toss it back to Shannon to see if we have any questions for the remaining time. Bob, thank you so much for another great presentation and wrapping up the 2019 year final webinar of the year. This is very exciting and thanks to all of our attendees for everything. Just a reminder, I was going to follow up email by end of day Monday with links to the slides recording anything else and diving in here on the questions. And if you have questions for Bob, please feel free to submit them in the bottom right hand corner in the Q&A section. So what are some examples of community of interest metrics beyond, for example, how many people attend the events? Well, how many people attend the events, but if they are responsible for identifying opportunities based on their community of interest, it may be the number of issues or the number of incidents or the number of opportunities that they've brought to the table. It may be the number of different communities of interest that are being created and as the person mentioned in the question, you know, the involvement of the people in those activities. Oftentimes the communities of interest don't have as specific metrics as the working teams themselves, but we want to engage. We want to make sure that people are being engaged, how they're being engaged, how much of their time are they spending. These are all things that can be measured when it comes to the community of interest. I love it. And, you know, we do have a couple, just a couple of minutes left, but we do have time for questions. If you have questions, just a reminder, if we don't have time to get to it, Bob will submit answers in the follow up email to your questions. So keep them on common. So what is the recommended frequency and duration of meetings for the working teams? The recommended duration, well, you know, it really depends on what the activity is that the working team is focused on. I don't know if I could give you that, you know, it's two weeks or two months or two years. It really is whatever it's going to take, a lot of it depends on how busy are these individuals in the organization? How much time do they have to spend? How important is it that we address the opportunity in a specific given period of time? So the amount of time varies. Typically what I find is that people don't like to attend meetings for more than 60 or 90 minutes. Just make certain however long you define for your working team meetings that you have an agenda that somebody again is leading the meetings and making sure that we're addressing all the things that need to be addressed in those meetings. Again, if there's downtime in meetings where people are bored or they're disinterested or it doesn't impact them, the chances of your working team succeeding for the long run decreases depending on the amount of time that you're requiring. We've got to keep in mind people have day jobs and the data governance working teams are not necessarily their day job. I love it, Bob. Thank you so much for another fantastic webinar and for always ending the year on such a great note. It was our, we just wrapped up our 89th webinar for the year for the 2019 season. So that's fantastic. Happy holidays to everybody. Again, I'll just a reminder. I will send a follow-up email by end of day Monday for this webinar with links to the slides, the recording, the matrices that Bob was displaying and anything else that he was displaying as well. Hope you all have a great holiday season and we'll see you all in the new year. Thanks so much. Thanks, everyone. Happy New Year, everybody.