 My name is Shannon Kemp, and I'm the Executive Editor for DataVercity. We would like to thank you for joining this month's installment of the Monthly DataVercity and DAMA International Webinar Series, Enterprise Data World. This Webinar Series is designed to give our Enterprise Data World conference attendees education year-round. We are excited to have just open rotation and to have announced the agenda for EDW 2015 to be held in Washington, D.C. March 29th through April 30th, so be sure to check it out and take advantage of all the early bird discounts available to you. And today's Webinar is being presented by a long-time well-known EDW speaker, Joy Medved. Today she will be discussing data governance, the four critical success factors, just a couple of points to get us started due to the large number of people that attend these sessions. You will be muted during the Webinar. For questions, we will be collecting them via the Q&A in the bottom right-hand corner of your screen. Or if you like to tweet, we encourage you to share highlights or questions via Twitter using hashtag EDW. As always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and any additional information requested throughout the Webinar. Now let me formally introduce today's speaker. Joy has been spent over the past 20 years as a business improvement consultant, strategist, coach, researcher, trainer, and speaker. Her areas of expertise include data governance, data quality, metadata, change management, and process information. She is a certified Six Sigma Black Belt and an information quality certified professional and always seeks to employ the most efficient and effective combination of methodologies and tools in order to help her clients simplify the quest for quality. And with that, I will turn over the presentation to Joy to get us started. Hello and welcome. Thank you for that lovely introduction. I hope everybody had a great weekend and good morning, good afternoon, good evening. If you happen to be joining us in the middle of the night, thank you so much for taking the time to be with us. As Shannon said, we're going to be discussing data governance before critical success factors. She already kind of gave a little bit of an overview, so I'm not going to go into detail on my background here. I do want to ask that if you have any questions, go ahead and post to the Q&A session. And if we can get to your question while we are actually on the slides, we will try to. Otherwise, we'll try to get to those slides at the end of the presentation. I'll try to leave some time for that. Excuse me. If you happen to be on Twitter, feel free to tweet, hashtag, dataversity. And Shannon, what's ever another hashtag? I think hashtag, dataversity will probably work for most people. Sorry, Joy. I was going to mute myself there. Sorry. It works. I wasn't expecting me to ask you a question. Sorry about that. Okay. So for today's agenda, I'm going to really quickly just go over what is meant by data governance to make sure that we're all on the same page. And then we're going to get into discussing the common barriers to building and sustaining data governance. And this is critical to dovetail into what the four critical success factors are. And then, excuse me, then we will wrap up with some key elements for successful data governance. To start off, what do we mean by data governance? Well, data governance by Dama, it's in their literature. And as you can see, data governance really has to do with the planning, monitoring, and enforcement of data governance. And it has to do with conformance with policy. So it's not so much, here's how we're going to do business, it's here's what we need to do within our business processes in order to make sure that we are conforming with policies that have been developed to ensure security, to ensure data quality, to ensure that our development methods are within compliance, et cetera. So I'm not going to go into great detail with that. I just wanted to share that one definition with you, as well as this definition, which I also love from the Data Governance Institute, Gwen Thomas. And she adds that it's a system of decision rights and accountability. And this is really important, this whole stewardship piece that goes along with data governance that defines who can decide what, when, under what circumstances. These are all the things that governance puts into play. So really, data governance does encompass that word governance. It's the how and what we need to do in order to ensure our business requirements are not only accurate but adhered to and can make the business as successful as possible. Okay. So, well, if that's data governance, then what is data management? And I threw this in because I did get a lot of questions from clients about, well, then what is data management? How does that differ from... And data management, on the other hand, has to do with managing required data. So it has to do with moving the data through the system, what's acquired, how it's validated, how it's stored, how it's protected, how it's processed, et cetera. Now there's a lot of overlap and I'm not going to get into all the details because I just want to breathe through this really quick. But they really are different things. So if you're confused at all about the difference between any of these items, data quality, data governance, data management, metadata, et cetera, there are a lot of resources online to help with that. Or feel free to give me a call and I'll be happy to discuss the topics with you as well. So what I want to talk about real quick before we get into the meat is the project and a program. Oftentimes I get asked, well, is data governance a project? Is it a program? What is data governance? So a project is really something that's short-term. Data governance, on the other hand, is really not a short-term one-off program. Data governance is very horizontal in the company. Data governance is an ongoing system that basically helps you define how you're going to run the business from a governance standpoint. And so a project, while it will include governance, absolutely, governance is itself not a project. A project is usually a combination of projects that get lumped together and it's a whole series of things that go on. As programs are ongoing, sometimes they're finite. It really depends. I've seen lots of different ways that companies handle programs. I've seen, I've had one client that said they absolutely have zero programs whatsoever. Every single thing they do is a project. And while that does have some problems, that gives you an idea that there really is no one way that that company is out there. So programs are different from projects in that they're ongoing. Sometimes they're ongoing, sometimes they're finite, but they're usually a combination of a whole bunch of different little projects that get managed in there. Then you have business as usual. And BAU is something that you really want to strive for with data governance. If you can get data governance not just built and managed but infused into your company culture such that it is ongoing, it is a normal day-to-day routine, then it doesn't seem like something that's extra thrown on on top of somebody's job where they have to do all this extra work. Because that then creates negativity and a lot of bad things. So business as usual, I find that the companies out there that are most successful and successful with data governance have built their data governance such that it becomes business as usual within that company. And everybody's involved with it. And we'll talk a little bit more about that later. Quick, I just wanted to show you what a data governance framework looks like. And this, again, is a DEMA framework. There are other frameworks out there. But as you can see, data governance is in the middle. And all the pieces and parts are around the outside. And everything intermingles. Everything is interconnected. So you can see that data quality management, for example, data development, these are their own entities, and they connect with data governance. So they're definitely not the same thing. All of these things are defined within this book by DEMA, if you want to look into a lot more detail about this framework. That is an awesome book to have. So we understand hopefully what data governance is and is not. Let's move on to the meat. Common barriers to building and sustaining data governance. So why do many data governance strategies struggle? This is a really great question. Over the years, I've been working with data governance with companies for about 10 years. I became a six sigma black belt in 2004, and that's when I started doing a whole lot more process improvement within data quality, data warehousing, and sort of slipped right into the data governance work as it started becoming more and more popular with companies. And over the years, I've sort of collected this interesting list of things that have happened that I've seen happen on the job. So what you're going to see now is kind of a combination, a brainstorm of all of these things that I've put together. Of course, as a data geek that I am, I use one of my tools. This is one of my favorite tools, the fishbone. So the fishbone is really great for helping to brainstorm and categorize the types of information. There are lots of you know about the fishbone. So I did this with the common barriers. So they organize this into four groups. The first group is lack of focus. And some of the barriers that I've seen that fall out of focus have to do with not having things like a charter, a mission, or a vision. Not having defined, specific roles, not having some sort of standard change management or communication plan and methodologies in order to educate and inform your staff about how you're doing data governance, what their roles are with data governance. Or simply not having data governance policies and procedures for all the company governance things. Interestingly, I've gone into several clients and they've said we don't do data governance. We want to start data governance. And then by the time I get a week or so in, I'm able to actually show them, yes, you do have data governance. It's informal. It may be a big lack of standard, it may be kind of haphazard, siloed in different areas. But through necessity, I find that a lot of fun areas have some kind of governance for the health. One of the things that is the lacking piece is the action to up and downstream functional groups. One of the things there is one person, or what one group does, doesn't always match what is needed downstream. So one of the things that is needed as well. A second area. Oh, okay, sorry. So when I'm doing focus groups, when I'm talking to people, this I threw in as an example of some of the things that you will hear. So the common barriers, this one group here, lack of focus, when I go in and I'm doing an assessment, a data governance assessment, we'll talk with a number of different people to try to find out not only what their needs are, but what the barriers are, what they see as the barriers. Well, oftentimes people are not going to say things like, oh, well, we don't have a mission. We don't have a vision. We don't have defined roles. That's not the kind of information that you're going to get from people. So whether you're an internal employee or you're a consultant going into a company, trying to figure out what the issues are in a company, talking with the people on the front line is obviously one way of doing that. So some of the things that you'll hear, people say you need to connect the dots for, this is an example. So for example, the second bullet down there, no one knows who should be working on that data stuff. No one says unless there's a special request. That's the kind of thing that you'll hear from people. So what does that mean? Well, basically you hear that coming from somebody. That tells me that there's a lack of defined roles within the company. First of all, if they call it that data stuff, there's a whole lot more going on that I need to tackle. But if there's no one person, if they can't tell me, yes, when we have this kind of an issue, we go to these people or there's a defined hierarchical structure of who handles what type of issues and who makes decisions within data governance, then there's obviously a lack of defined roles and responsibilities and accountabilities, et cetera. So this kind of gives you an idea of things to listen for so that you can start narrowing in on what barriers there are. So the second group is lack of understanding from the company itself. So if there is a lack of a lack of new hire training, a lack of communication, if the company has not embraced data as a strategic asset and if there are no data governance measures and metrics, things like that that provide the information to the company, if those things are missing, then you're naturally going to have a lack of understanding. And some of the things that you'll hear in that category are on this slide. So, for example, the second one, this is one of my favorite ones, and this is true. I've actually heard this from multiple colleagues. We don't need to know about data quality because we don't use data. That's what IT is for. Now, as a data practitioner, that probably sounds to you and it probably sounds like I made that up, but I didn't know honesty. I have heard that from many people. Oftentimes, people in customer service, sales, different areas within the company, they don't see that they actually use data. They say, oh, I do customer service. I handle complaints. So I work with complaints from customers. Well, all of that information, the customer information, the product information, the service information, the complaint itself, the process of where that complaint goes, the escalation process also falls within data on some level. So if I hear somebody say that they don't use data or that IT is for, then I know there's a lot of misunderstanding, miscommunication, a lot of lack of understanding in the company. This area is lack of support. And there's mostly this has to do with lack of support from executives and stakeholders. The way you can see this is it's not a priority. Data governance isn't seen as horizontal. It's siloed. For example, they might have IT governance and that's the only governance that they do and it's run completely internally by IT and the business has no knowledge of what's going on. Obviously, people in politics, there can be a lot of things that are preventing data governance from moving forward. I've actually seen some executives who have personal pet projects within a company sabotage data governance efforts so that their own data can move forward. That's an extreme situation. It doesn't happen that often, I hope, but that's an example. And the lack of compliance enforcement, that's a huge one. If you don't have the authority and the responsibility to be able to move forward with data governance, if you don't have that senior executive support in order to enforce the compliance with data governance, then you're not going to be able to move forward at all. It's going to inhibit you. Some of the things, for example, we can't or don't feel comfortable telling other managers how to run their groups. Something like that, they really don't understand data governance. They probably don't have data governance counsel, which actually helps to manage that piece of it, and they don't have the executive support because a data governance manager really can't go across the entire company horizontally and tell people how to do their jobs so that they can comply to data governance requirements. That's not the data governance manager's job. They're there to help manage the policies and procedures themselves. They are not the person who goes out and enforces compliance. That really needs to come from the top down. If you have a manager who keeps, well, I keep going around telling everybody if they're not complying and nobody will listen to me and, you know, the vice presidents are never around. I can't get their support. Then you obviously have a problem with executive support. The executives themselves should be pushing from the top down. Not only that data governance is in full force, but that they need to comply and then enforce whatever happens if they don't do what they're supposed to be doing. So things don't get signed off. You know, if things get signed off, for example, if you have governance in the SDLC process and they get signed off with the work being done, then that's also an indication that you don't have executive support. So how do you keep enforcement lightweight so it's not considered so heavy that folks just end running? Well, that's a really good question, actually. And compliance is a whole area in and of itself that we can talk about. But really briefly, if you have executive support and you work in data governance to business as usual within the company, then it's not really enforced. It's just business as usual. So what I try to encourage companies to do is get to the point where you're building data governance into the day-to-day routine of your business processes. That way it's just another step. It's not this big thing that's landed on somebody's desk that says, we're going to enforce, blah, blah, blah, blah. You know, you don't want to come in, you know, with the handed Nazi thing going on. So, you know, you can look at any given things like doing time cards. You know, if time cards were looked at as this big extra thing that everybody has to do and it's a horrible thing and it's not part of their job but they really have to do it and then it's going to be a negative thing. But that's not the way time cards are looked at. Everybody just does their time card. So technically, if you're looking at a time card, really isn't part of your job description. That's not required to fill out a time card. But it's necessary to fill out a time card in order for certain administrative duties to get done by HR. So that's not something that the business is out to do so that another functional area can accomplish their goal so that you can get paid. Well, that's the same thing with data governance. If data governance pieces in part are built into the business processes, so that it's just part of the business, then that's just part of the business. It's not this big extra thing that people feel like they're being monitored and forced to comply to things. So I hope that answered the question. I wish I could get to it, but we don't have time in this hour. Is there any other questions? Shannon? Nope. I had to speed up my mute. Okay. So let's go ahead onto the fourth section, so make sure we don't get behind in time here. So the fourth section is lack of resources, and this one is very obvious. Lack of funding, lack of time, lack of people, lack of skills and experience. So hiring people, but they really don't understand what they're doing or bringing in a tool but not hiring somebody who actually knows how to use it. In other words, the traditional replace skill with the tool and thinks that the tool is going to do everything you need, but then not having anybody who actually knows how to run the tool properly or do analysis properly. And the big one I like is not built into projects and programs. If I go into a company and they have an SDLC process or they have different data projects going on and there's no metadata they've collected, there's no data quality metrics being assigned, then that pretty much tells me that there's no data governance built into their projects and programs. And one of the things that you want to do as soon as you get established is immediately start building governance into projects and programs. Governance can absolutely be done iteratively. It can be done slowly at first, but the key is to start getting it into the projects and programs so that it can be seen as a normal part of the SDLC process, a normal part of project management. So that's just another step, like I said. It's not this big thing where they say, in addition to all this work that you're doing, we're going to dump 10 things you've got to do for data governance. And you don't really want to break it out like that. You just want to quite large it in as another step that they have to do. You know, very unintimidating that way. This one's pretty obvious. Obviously, things like lack of waste of time trying to track down metadata resources that end up not existing. Well, if you don't understand how to build a report and you don't know, you know, there's a field called Custer, but it's in four different tables and you don't know which table is the correct table and there's no metadata to check it against. That's an example of lack of resources. There's a lack of metadata. You're trying to track down the person who knows and they're on maternity leave and nobody else knows. You're going to run around wasting a lot of time and money and probably have a lot of mistakes in whatever it is you're trying to accomplish. So, lack of resource. And keep in mind that these things are just shared with you. There's no particular order or priority to them. They are all equally as important to identify and take care of. One of the things that I want to point out here is to identify whether or not the barriers are specific to symptoms or causes. If you put a band-aid on a bleeding artery, you're really not going to make much progress in fixing those barriers. So, one of the tools that I love to use is called the Five Wise. And obviously, basically what it says, you ask why, you get an answer, you say, well, what why, and you get an answer, they will put why. And if you ever have a question as to how this tool really works, go talk to a two-year-old. Two-year-olds are natural data quality people in my book. A two-year-old will absolutely demonstrate the perfect Five Wise, although I know sometimes they get into like 10, 15, 20 wise, and then you have to kind of drink because they're driving you nuts. But that really is, you know, it's beaten out of us. We naturally want to find the cause of whatever it is we're interested in. And as kids, we're told to stop asking why. I know I was. I would ask why all the time. And I can remember, even as a little kid, my mother yelling at me to stop asking why. And of course, I didn't listen, which is why I do what I do today. But definitely you want to get to the root cause. And you want to kind of stop at one point where you have a feasible to be able to have the resources, the time, the money, and the people to fix what you can fix. So you have to be realistic about how far down you go. So you definitely want to get to the root causes. You've got to find the root causes before you can fix them. So now let's get on to the common barriers. I'm sorry. So this is just a recap of what we just looked at, the common barriers. Now this goes directly into the four best factors. So based on those four categorizations, the four critical success factors are the focused strategy and plan, the company understanding, full down support, executive support, stakeholder support, and ongoing funding and resources. So now we'll talk about those in a bit more detail here. So the focus is strategy and plan. And just like the barriers, it is having a charter and a mission, having that communication plan, having the defined roles and responsibilities, identifying and articulating what your priorities are. If you don't know what your priorities are, there's no way you can articulate them. I've gone in, as a matter of fact, last year I had two clients I went into and both of them had similar issues. They had started a data governance program a couple of years earlier. And when I got there, one of the questions people kept asking me was what is data governance? What do they do? What does the data governance office really do because we don't understand? So if you have a data governance office for two years and you still have people saying, what do they do? You don't have an articulated priorities or you have a lack of communication about those articulated priorities. One is the company understanding. Without training, without required training, this doesn't have to be massive data analytics training for all your staff. But within onboarding training or within each functional group, depending on the person's role in the company, you don't want to have training as to what data governance or data quality or whatever is. I did have one company I went into a number of years ago and I was responsible for developing a series of data quality training. And the company actually did it really smartly. Instead of just having a training that was data quality, you know, what is data quality at this company, what they do is go around to each functional area and talk to the managers and actually develop a tailored training for that department. So this was actually an oil company and so I developed a data quality training for geologists and data governance training for the geospatial group. So all the examples and the data that they were looking at directly move out of their job, the data that they use so they could understand data quality from their point of view. And I thought that was a brilliant way to do it. The third one is full top-down support. Again, you've got that stakeholder and executive support from the top-down. Data governance has to be considered a priority or it's not going to get built into the system. Obviously, without top-down executive support, you're not going to have that compliance enforcement capability. It's ongoing funding and resources. Again, very obvious. You want to make sure that you have dedicated time, dedicated people, ongoing funding. The correct skills and experience is necessary. You're obviously built into projects. And then your automated or other technologies will help with data governance, et cetera. At this point, I want to just stop really quick and ask you if there's any questions up to this point. All right, now. Okay, awesome. So, the key elements for successful data governance. In the work that I've done over the years, these are just some things that I've put together in order to help ensure data governance success. And many of the things that I'm going to share with you right now, if one or more of these is missing, you're really going to have some issues with data governance. You sometimes get away with iteratively building these things into your program. But if you've got, you know, if two major things are missing, you're really going to have problems with successful data governance. And the first one I always tell people is that top-down executive and stakeholder support. Really, without that, you're going to have a lot of problems, like the example I used earlier about the data governance manager, who is trying to, themselves, enforce data governance across the company. And I have talked with a number of people who have been put into that situation. And it's very stressful. It's very difficult. And they usually end up being called, you know, the pay to Nazi or, you know, the interesting names. And people start running when they come down the hall. And that's not what you want to do. The data governance manager really needs to be a support and a friend to all of the functional areas across the company to help them with their own governance. So you don't want to put your data governance manager into that position. And if they are, occasionally, you can do proof of concept and take the information up and gain top-down support. But it's very, very difficult. I just had a conversation a couple of weeks ago with somebody who has been trying for five years to get executive support to start data governance. And for five years, he said, I think they finally are starting to understand. That's a long time to have to go without having successful data governance. And then there's a focus charter with clear mission and vision. I have had... I did have one client recently who said to me, no, we don't want a charter. We don't want to do any of that. We just want data governance. And I think it can be done that way. I would not recommend it. I think having a charter clearly defines what the data governance office is going to do, who is going to be involved, what scope you're going to tackle. So for example, you may want to tackle master data, or you may want to tackle a particular area like marketing data, or you may want to tackle a particular product initially. And so having a charter that says, okay, for enterprise data governance, here's what we're going to do, ultimately, but we're going to iteratively, over the next three to five years, plan to start with these products or these data areas or whatever it is that we're going to do. So if it's articulated, if somebody comes into the company, or if somebody in the company says, you know, I really don't understand what that data governance office does, you can hand in the charter and say, no, look, we really do know what we're doing. We've got focus. We've got a mission. We are working on something specific. We're just, you know, hanging out, collecting money, you know, talking about data all the time. So having identified priorities, actually having identified priorities, which is what I was just saying, goes into the charter, understanding exactly what it is the governance office is going to work on so people know what to expect. So policies, procedures, and processes. Now this is amazing for some people. I've actually had people think that this means business processes and business policies, and that's not what this means. Defined policies and procedures within the data governance office are actually data governance policies for procedures and processes. So just as everything else needs to be governed, so does data governance, which is why there's usually a data governance council of some kind that oversees and helps check and balance for governance itself. So governance will have a lot of policies and procedures that define how they operate, how they interact with the other functional areas, how to collect the information that they need, how they do their sign-off. So these differ from the business processes that have data governance interjected into them to ensure that they are complying with data governance. So leadership roles and responsibilities. This is extremely important because a lot of people will say, well, it's not my responsibility to collect your metadata. Well, I do that. I'm a whatever. That's, you know, I'm not a doctor, Jim, not a specialist, right? So this is my job. But if you look at it, a lot of times the people that you're talking to have leadership roles already. It's just not formalized or it's not defined that way. One of the things that I found when I go into a company and I'm starting a data governance effort and there's a pushback and people say, hey, you know what, we're already overworked. Don't tell people that you have to add this onto their job because they're just going to hate it and they're already, you know, hating the fact that we're doing this. But what I want to try to do is find out what the person's role already is and how they're interacting with the data, whether they're, you know, if they're involved with the STLC process, for example, doing development work, even as a business person, you can say things like, well, hey, you know, as the business person who's doing this development project, given business requirements that define certain things, what are certain things? Well, you know, you came up with this new field. Are you telling them what that means? Well, yeah, of course. You know, I'm telling them what the calculation has to be. I'm telling them, you know, how it's defined. Well, that's metadata. So you're already doing metadata. Oh, really? That's metadata? Yes, that's metadata. So now that you've just educated them, now they're using proper terminology, and they realize that it's not something new that they're being asked to do. They're being recognized for what they're already doing. And so that's a key thing to helping people understand that they're being recognized for the role they're already playing. You're not asking them to do all this additional work. And so that's the key thing. Now, as we mentioned, that a governance council really is made up of the higher level executives that ultimately govern what's going on with governance. So it's kind of a checks and balance. Now, I have seen governance committees and governance councils in a lot of different ways. I'm not going to go into those because we don't have time to go through all those different types of iterations here. I've seen companies that only have one committee made up of senior managers and directors who basically do all the deciding and all the managing. And that's all the company has. I've seen models where a company will have a data governance council, high level executives, as well as a separate stewardship committee made up of managers and leads who do a lot of that work. And I've seen companies have three. They've got the high level data governance council. They've got a senior manager, director of management that basically does the footwork for management and enforcement. And then a technical committee on top of that that actually fields the bug reports, the new requests, they handle the risk management, they hash out the definitions. And all of these groups, in my opinion, need to be made up of both technical and business people. So regardless of the type of model that your company chooses to employ, the key is that you need to include both technical and business people so that data issues can be discussed from all levels. So I forgot one other model I've seen is smaller companies will sometimes choose to integrate the data governance council into an existing executive committee. So regardless of having another agenda, it becomes an agenda item on an executive council committee. And I've heard, sometimes that works, sometimes it doesn't. It depends on how busy that council already is and how much governance work needs to be done. So if you have a small enough company and there's a small enough amount of work, that could work. You could couple that with a stewardship committee that does a lot more of the work as well. So obviously that's a whole other area that we can get into a lot more discussion as well. And then we've got dedicated and ongoing funding technology and staff. That's pretty self-explanatory so I'm not going to go into great detail on that one. We have a defined communication plan as well as change management and training plans. These three areas, communication, change management and training, I really feel strongly are very, very important to the success of the data governance effort. Without the communication, the business tend to be very siloed. Most companies don't come out as, you know, a $5 company from the get-go with everything organized and communicated. They start small. So a lot of companies will start with a few people and over a period of time they grow and grow and grow and grow. Some companies grow really, really quickly, especially when a company grows very quickly. They don't have time to put in that formalization, the policies, the procedures. They're barely able to keep up with the work that they're doing. They're hiring the minimum amount of people just to get things going. They're trying to make a profit. They're trying to do things as best they can. And so oftentimes documentation goes the way technology often isn't brought in until they're much bigger. So there's a lot of manual things. And because functional areas tend to operate very siloed, this intercommunication between cross-functional areas tends to be one of the last things people put in place. So when it comes to governance, actually one of the benefits of data governance is helping to unlock that siloed system. It forces the business unit to talk to each other. The plan, which communications and change management is, again, a whole other area we could spend a lot of time on. We couldn't think of the term. So the few innovations on who to talk to, when to talk to them, how to talk to them in order to achieve effective communication is a whole science in and of itself. Understanding your people, understanding how to build a successful change management communication plan in order to achieve optimal communication can go a long way. If you talk to the wrong person at the wrong time with the wrong message, you're going to, in effect, sabotage your effort because they're going to be upset. They're not going to like it. They're going to go and spread their opinion to other parts of the company, and then you're going to have a much more difficult time on your hands to get data governance off the ground. I have had several clients, most of my clients, and the first thing they say is, we've done data governance before. Nobody's happy with it. Everybody hates data governance. So whatever you do, don't use the words data governance and don't say change management to everybody because the first thing they'll do is walk away. And that's the key indicator that they have not done proper communication and change management in the past. And now everybody is turned off to the terms, which makes it very difficult. I actually had one client who said, you need to create a whole new method of change management to implement without telling anybody that you're doing change management. And I was like, oh, wow. You pretty much can't do change management without communication. So that was very interesting. Interesting one for the class. And that's something as well is very important. So required priorities in all projects and programs again, this is something that you're going to want to start out iteratively, start out with a few things here and there as you build the processes. Oftentimes what I see is IT will be involved in a series of projects. And obviously some are already in place. Some are about to start. What I would usually recommend is don't look back unless it's a project that is going to have a second phase that hasn't started yet or there's a specific need because it relates to another project that's going on. It's too much work to go back and try to add hours to an existing project or implement things once everything is in production. So don't worry about going back unless it becomes a priority for other reasons. Start with something that is just starting at the point in time. Once your policies and procedures are in place and you've talked with the PMO and IT is on board with getting data governance infused into the STLC, the System Development Life Cycle that will start. And over time, as you add to existing or each subsequent project, over time, eventually you will be infused into all projects and programs. We'll go back in a little bit. You'll have metrics monitoring and reporting. Again, this is specific to data governance. You'll implement a lot of metrics and monitoring for various things. You're going to monitor security who has authorization, who's been accessing certain systems. You'll have metrics for data quality. You'll have monitoring the progress of metadata efforts, et cetera. So all of these things will have their own metrics and monitoring and reporting. So we'll take that from a data governance standpoint, mostly to start collecting information on the adoption and the acceptance within the company. So if you have certain policies and procedures for data quality is one of the simplest ones, collecting metadata. You can actually put metrics in place that monitor the progress of collecting metadata in the STLC. Very simple metrics. Some have to be highly complex, but it's something where you can go to executives and say, look, we have statistics showing that we are getting adoption. We are getting acceptance. People are adding to the metadata repository. We are getting these things. We've got certified reporting. As of this month, we have 100 certified reports. Those are the kind of things that you can put numbers around. And it also helps justify ROI. So once you start collecting metrics, there's ways that you can go around and actually start putting dollar signs to that and start proving your ROI for your data governance effort, which is often challenging since most people see data governance as an overhead expense. But you want to bring it around to show that you actually are saving the company money. And this is one way that you can do it. So compliance and enforcement. This is a huge area and there's different types of enforcement from manual to automated. Lots of pieces and parts to this. But what you want to make sure you do is put in place some sort of compliance enforcement to make sure that all the work you're doing is actually going forward. And part of this is what I was just talking about, the acceptance and accountability and responsibilities for stewards, et cetera. We have a really great data governance program and nobody is using it because there's no compliance, then you just wasted your time. I do actually hear from quite a few companies who say, well, we want to do data governance, but we don't want anybody that they have to use it, so we're not going to do the compliance piece. Well, pretty much should just not do it then because that tells me that the company is not at the maturity level to implement successful data governance. If the culture is such that nobody is going to pay attention to the policies and procedures you put in place, then you really should be spending your efforts making some data quality metrics in place to have some ROI or statistics showing proof that you have data quality issues that you need data governance in order to help ensure the quality of your data. So that's that. Part of company culture seen as business as usual, I was talking about earlier, if data governance is not part of your company culture, it has to be built into your company culture and needs to be seen as business as usual. Like I was saying earlier, build it into the existing policies. Every department has existing procedures, whether they even realize it. Process improvement work, I get in and I don't just say, okay, here's how we're going to do the process, here's how we're going to fix it, blah, blah, blah. What I usually do is I talk with the stakeholders and say, okay, what is your process? They say, okay, we do this, we do this, we do this, here's our process. Then I go and I talk with people and I say, what is the process? Then I talk to the stakeholders and I say, here's what you said the process is and here's what your people say the process is and here's the delta. There's a big difference. Then we develop what the process should be. We re-engineer it, we do the improvement and I say, okay, now we've come up with what your process is going to be and then ultimately at the end of the process, there's a final process that says, okay, here's what was implemented. So they force set the flow charts I do for clients when I do process improvement work. But the key here is, every time the process is whether they're formalized or not and once you start flow charting that out and adding some of those controls for clients in there, it just becomes a process improvement effort. It's not, here's all the data governance you now have to do. It's, oh, we have a process that's really redundant and takes this person three hours. We can re-engineer this through a couple of data governance things in here and now it only takes the person two hours and it's more efficient and the person downstream gets the report they need it to be. So there's a lot of interdependencies and interrelatedness there. Data accepted company-wide as a strategic asset. This is something that actually, as data as a strategic asset is, if a company has embraced this, they will have that as part of the company decision. It will be within the company charter, it will be at the company level and all of the units across the company will have within their processes data governance, data quality, whatever it is that that relates to their group. So they go into a company and they say, oh, yeah, we embrace this as an asset and it's part of our mission then half your battle is already done because you know you have executive support. You know that people have been educated on what data is and data governance hopefully and you've got a starting ground. If you go into a company and there's no data as an asset, they don't even know what that means, then you really have to start from ground zero. So that's a great idea for me. But ultimately if you get to the point where it's part of your company culture, data governance processes are business as usual and the company understands data as a strategic asset, then that's ultimately where you want to get your company to. So without that, I'm going to turn it over to Shannon for questions for the remaining ten minutes that we have left. Perfect, and we definitely have questions coming in and of course one of the most popular questions that we always get are questions about the slides. Just so everybody know, we will be sending out an email or I will be sending out an email by end of day Thursday with links to the slides and links to the recording of this presentation. So the critical data governance tasks and deliverables that should be in the SELC. That's a really good one. So a couple of the foundational pieces, like I consider foundational pieces, has to do with data quality and metadata. And then security is pulled in there too because you've got authentication and access and those kinds of rights. Why would a company try to identify those within your own company? Take a look at your business requirements. Your business requirements and data requirements. If you've got business requirements that say, you know, we have to be able to track whether or not the quality of the data is matching what we need for XYZ, then you know that data quality is going to be an important facet. So what you'll want to do is build into the SELC process checks and balance to ensure that not only is data quality being done throughout the project, but also will continue to be monitored and reported on as a product. So as the deliverable goes, you'll want to do things like collecting metadata and you need to within the data requirements and business requirements to find what those are. You know, do we just want definitions? Do we also want precision formatting, you know, all the other pieces and parts that go along with metadata? A whole bunch of things. So it really depends on your company and what you want to collect. Sign-offs are a big thing. You want to make sure you have sign-offs within the SELC. So you're going to, for example, bigger companies that actually have a data quality department and a metadata department and a data governance department will have sign-offs from all of them. You know, metadata will have to be signed off by your metadata person. If you're a smaller company and your SELC can only include one poor data quality person who has to do everything, then that person would need to sign-offs. Yes, we have the metadata. Yes, we have the data quality metrics. Yes, I've done source-to-target validation. Yes, our data governance processes have been adhered to. And then data governance will look at that project and say, has the data quality person signed off? If the data quality person is signed off and data governance says, okay, yes, signed off, we're good from a data quality standpoint. The signs are really, really, really, really big. Another big one would be SLA's for collecting data and managing data. And I want to get into all of that. There's a lot of other deliverables that you can look at. But sign-offs and SLA's, I think, are two big ones you want to take a look at. It's a good strategy in an hour. It is. Well, I paired this down from a half-day's tutorial, so there's a lot of information. One of the attendees would like to know your thoughts on what the importance of data governance after most of the data quality issues have been addressed, and do data quality rules are in place and everything is moving along. Okay. I'm going to show you the slide that I just applied to real quick. That I showed you earlier. As you can see, data governance is not just data quality. It has a lot of different pieces and parts to it. But data quality and data management, you've also got database operations management. You've got reference and master data management, data warehousing, and BI management. So this year, data quality has gone through the development process and you're in production and you're just monitoring and managing existing data elements. That's not where governance stops. And in fact, governance on quality stops if you're too familiar with Tom's dirty lake analogy. You're constantly using the lake. You're constantly using that data. If your data is 100% static, then once you get it in there and cleaned up, you're good to go. But literally, do I ever see static data from a company? Your reference data might be static. Some of your other data might be static, like you look up tables and code tables and things like that. But in general, data typically is not that static, which means anytime you have somebody touching your data, you have a room for data quality issue. So it is an ongoing effort. But as you can see from this slide, there's a security document, contact management. There's a whole lot of pieces and parts that you'll add. It is a full-time job. And just to give you an idea, Mario Ferrara was a keynote at DGIQ last year. And he had hired me at a company to be the senior director of data governance and data quality. And at the keynote, he said, no, now I realize that data governance and data quality really are two full-time jobs, which I went up to him afterwards and I thanked him. I was like, yes, they really are. And he hired me to do them both at the same time. They really are two full-time jobs. And every single one of those areas on this wheel are full-time jobs. And they're teams. They're departments, depending on the size of your company and the number of products and services you have. So it's not something one person can do. It's not something you can do while you're doing something else. It's not something you do temporarily and then go back to your day job. It is ongoing. You really need to put some effort into it if you're going to make sure that it's going to be successful. All right. Question here. Do you have any examples of charters, policies, roles, responsibilities, communication plan, et cetera, exist? We don't have a DG council yet, but have been asked to create a number of the above. We want to avoid being overwhelmed by recreating the wheel. That's a good question. Yeah. You know, I have my own template that I've created over time, and I know, like, like, regular consultants, we don't usually give that information out online. So I'm not sure how much is actually out there now because I haven't looked in a while. But I know, you know, anytime I need, I need a template for something or an idea on how I want to create something. I do a lot of research online, and I usually pull pieces and parts from what other people have done. Oftentimes, you'll see full documents and templates from academia because they'll post a lot of their stuff out there. Plates and cells, a lot of times you'll have to pay for. Companies will put templates together and then sell them. I don't have any off the top of my head to give you. What I could look is part of my theory procedure. So if you're familiar with Robert's Rules of Order for part of your procedure most non-profits use Robert's Rules for a lot of conduct business, a lot of times within parliamentary procedure documents it'll say you must have a charter that says you must, you know, what is your vision? What is your, and that could give you an outline of some things you might want to pull from. But I, sorry, I don't actually know of any place online where you can just go and get these kinds of templates. Although, I'd be happy to work that out with you. We'll make sure that everyone gets your care or information. Looks like we actually have a time for one more question. What is the commonly realized value from data governance? The most realized value. That's a great question. I think it's a common value that I try to help my clients see and what they're most surprised about seeing is that by implementing the data governance eventually companies see that it's much smoother. They have issues with their data, their communication between the cross-functional areas. So in general, what they consider overhead data governance, data quality work. In general, actually becomes more cost-effective. And most people I think are really surprised by that because they think of implementing data governance as being a cost to the company. And that's all it is. It's like, okay, great. We have to do regulatory compliance. So now it's going to cost us this many, whatever, million dollars. But ultimately, when you start implementing this stuff, no matter why, it actually shows that not only does it pay for itself, but you end up saving money. A real quick example is metadata. On the slide I do on one of my tutorials showing how much it costs the company to ask questions. So you can break it down to an actual dollar amount, how much it's costing a company to just have every person in the company ask one question a day, how much time it takes to get that question answered. Whereas if you had a metadata repository that people could go to and look that information up themselves, you would actually save a lot of money. And that's one thing I used to help justify metadata repository work. So ultimately, I think it's going to cost money, but it ultimately ends up saving a lot of money in addition to making the data estimate a lot more efficient and effective within the company. So that's all we have time for. And I'm so glad we finally got to do a webinar together. This is great. Thank you for asking me. And like I said, I'll get the e-mail out to everybody by end of day Thursday with links to the slides, links to the recording, and along with Joyce, contact information. And of course, you can meet her in person at Enterprise Data World 2015 in Washington, D.C. We hope we can see you there. And thanks for everyone for your participation today. We love it as always with all the great questions and everyone getting involved in everything we do. Hope everyone has a great day. Thank you for your commentary. Bye.