 I'm the executive editor of DataVersity. We'd like to thank you for joining today's DataVersity webinar. What's the DG? Small SAS. I just love saying that title. 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, you'll be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you like to tweet, we encourage you to share your questions via Twitter using hashtag DataVersity. As always, we will send a follow-up email within the two business days containing links to the slides, the recording of this session, and additional information throughout the webinar. Joining us today is Kimberly Navala. Today, AKA the governance guru of the SAS best practices team is responsible for industry education, key client studies, and market analysis in the areas of business intelligence and analytics, data guidance, and master data management. The author of Sustainable Data Governance, the Data Governance ebook, maps, mechanics, and morals, 10 mistakes to avoid when launching a data governance program, and the analytic enterprise. We're lucky to have her with us here today, and with that, I will give the floor to Kimberly to start the presentation. Hello, and welcome. Thank you. Thank you, everyone, for joining me today on what, at least here on the left-hand side of the coast, is Grand Blustery Day at the SAS. It's not appropriate, because we're going to be talking today about indicators that army weather may be ahead for your data governance program. What I'm going to walk you through today is some of the common pitfalls and barriers that create a governance program to help her stumble, and in some cases, outright fail. And this is really to provide some food for thought to either begin or continue your data governance journey. Today is not necessarily to provide descriptive relief necessarily, but to really help you diagnose and identify some of these common causes for you to actually become mission-critical within your organization and within your program. It's interesting, because to some extent that was a very gloom-and-zoom intro, but in a lot of cases, some of the issues that we're going to be talking about today were often, as programs start to grow and mature and gain traction. So the thing is that your program will grow and mature, and the bad news is there's some growing pains that come along with that. And unlike the growing pains that some of us experience in our teenage years, unless we actually deliberately and actively address some of the new issues, they may not signal a death notice to which if you wish for your data governance program. And they can require data governance to become a bit of a spoiler in a lot of organizations. So particularly, we're going to sort of keep in the nose of a tentative, typical company who is struggling to address and overcome some of these problems and issues. I'm going to start with a little bit of a... So, kind of joining the staff. I worked for a management consulting company. A lot of the work that we did was actually engaging with companies to develop both data strategies and help develop and define their organizational framework around data governance. And we were working with a very large retailer on the course of their discovery activities as a member of the executive. And the course of conversation was one particularly vocal. He supported him. Exactly. He said he gave us... He kind of wanted the reasons why they needed data governance. We adjusted him the value. And it was quite clear that he got it. And then he said, I'm curious to see what he's not going to do. This is not success to me. And he turned around and picked up something from behind his desk. And then he turned around and dropped it on the desk. He was actually a binder. And it was a binder that was about three to four inches thick. And one of the titles of the binder was The Debt It Was a Customer Data Governance. And he did this. Debt recreates this binder. And what's actually interesting about that is what we do, and I call this sort of the academic approach. When we took a look inside this binder, we found out that the creator's binder had done a very, very good job of thinking through increasing all the team value in the eyes. They had thought about the short and long-term objectives for data governance. They had all of the new role, processes and procedures that might be needed in the short, medium and long-term for the program. They had some, you know, prototypical workflows, like automation, mechanism, et cetera, et cetera. It all really could work. But the only place that that actually was was in the binder. Because in terms of with positive intent to try to really account for every possible objection and identify every eventuality, they had really just overcomplicated the process. And it was incredibly overwhelming to the organization at large. The organization really looked at that binder and ultimately just scratched their heads and said, we don't know what to do with this. We don't know, this looks good on paper, but we actually have to translate that into data governance on. And so it looks like I'm going to just pick up my headphones and let me know if this is good or not. All right. You were fine. I'm not leading you up, of course. Okay. So if that goes in and out, this might just be storms, so technology. So what we call this, and so this is one of the first topics I want to talk about, is this idea of the academic approach where, and we see this happening in organizations in one of two ways. You have folks who really get it, and in fact, they're a little bit actually overzealous. Right? We're so excited about bringing this to the organization and all the things that we know that can be done is that we actually sometimes overwhelm the organization with too much information too fast. Or specifically, we know the organization has some resistance and we are actually trying to, as I said, account for every possible objective and objective upfront. But the point is that in doing so, we just made it too complicated. We got overwhelming and somewhat ironically, played into some of those objections. So it's very, very important that as we go forward with data governance that we do develop a strategy and that we do design the program, but that we can very deliberate bite-sized chunks. And we're actually actually communicating and developing new processes, putting models in place. Just in time, just in time when we actually need those to get the current job at hand done. And Peter, I think, said this very well. He's a noted corporate strategist and consults with a lot of the biggest companies in the world. And he said, it is more important for organizations to do, he said, or one of the recommendations is organizations do nothing. He said, you need to do zero than to do four things badly. He said, you need to look at and focus on those areas and develop the roles of practices and incorporate these new actions in a less-wise fashion. And in other cases, he said this is more when it comes to data governance. He said, it's interesting because it's not very deliberate in doing this. He's very anxious and what people don't understand that they actively resist. And this actually then brings up a very issue. That issue is that in the interest of trying to get people on board the data governance bus at the council levels, but there's a lot actually at the data stewardship level in particular that we have a tendency to want to make it easy for the organization. And after that, what we tend to say is we get that resistance because people don't understand how this works. I'm not sure what I should be doing. What we're saying to them is, hey, don't worry about it. It's going to be easy. I'll take care of it. I'll take care of it for you. And we fall in the trap of becoming the doers as opposed to the enablers of the data governance and data management practices in the organization. And this is actually a bit of a problem because what we are doing with good intentions at that point is we are relieving our organization of accessibility for data and we're allowing them to not actively engage. Now the governance is now our problem. It's a problem to need a data governance council. It's a problem of the data stewards. And what we know is that if we could have fixed it, our rules in the first place, we wouldn't have needed data governance at all. One of the hardest things, and this is particularly true as you move out of that initial phase where you're cutting and doing some of those precept concepts is operationalizing analytics. It's for us to change our mindset to maybe a more consultative or facilitation oriented mindset that says, for example, for instance, as a data steward, it's not to do the data management, et cetera. My job is not to be the subject matter of all things data, but my job is to actually know who those people are and help them facilitate their work, help them collaborate amongst themselves. And I'm here to actually translate and connect those subject matter to the organization. And work with and find those key influencers so I can develop a very active and engaged community of practice. And again, it's a very specific mindset and we see this in a lot of areas, like data stewardship in particular, where subject matter experts are not always good data stewards, but a data steward may be a good subject matter expert. And the critical success factor there tends to be the individual's ability to actually facilitate and communicate and to drive toward consensus versus how well they know a specific topic or domain with their organization. Okay. So, the next two of the is that we see in organizations, the sort of academic approach where data governance is an activity on paper and the propensity of some of those early ways to want to do the work on behalf of the organization. But let's take a look now on a different hallway now. And the next one here is what I call and what I want to talk about this is that in a lot of cases it isn't easy for organizations to do things like stand up a new role like a data stewardship role or even to create a data governance council. One of the things that we tend to overlook is not just creating the role and accounting them with some responsibilities, but how can we actually embody them with the authority to carry out those actions and reach those goals that we're getting. And what it starts to look like is that we have counselors or data stewards who become a bit of roving line back first. When the conversation starts to look like this they say, oh man, what could you do? Here, Kimberly comes again. Who are you meeting anyway? Well, what is she supposed to do? These are things that we're not necessarily doing again in a very deliberate way. He's not saying, hey, here's some new roles with some new responsibilities. Here's Kimberly and here's how those activities and the actions of these different roles and people actually impact our existing practices. We're actually building these data stewardship, these data management activities into our business practices and into our software development life cycles. And the one to which we're not doing that is with which data governance just becomes a matter of if I like it, I know Kimberly and some of them that help her out type of activity. This is actually very frustrating for the different council members and data stewards as well because as they're going about their business and trying very, very with good to these really just scratching their heads and asking themselves, how in the DG did I get here? And how is that actually supposed to draw attention within the organization without the support, without that very discrete state and function? And it's interesting because one of the things that's probably the easiest to do but it's something that we see organizations don't do a lot is very, very deliberate what that all means. So many data stewardship just because it's the only one. The reason that a data steward is actually going to do is because of the decisions that they are allowed to make, what are the sort of hurdles and thresholds for the organization as a whole when they engage a data steward? Why not? When you have an issue that a data governance council should look at and what's the hurdles and thresholds for you as an individual or as a project team can make a decision for when you need to engage a data steward or for when they actually need or you might need to engage an executive data governance council or an executive committee. So one of the things that we work with organizations a lot is to be very deliberate in defining it. What that means, what the role is is how the role intersects with existing processes including the development lifecycle. You know how all projects are prioritized and dealt with. What is, what doesn't and when do I need to ask? And there are several tools that we've used for a long time that are very powerful in doing this. Things like a racy or record for responsible, accountable, consulted and informed and it's a way of defining who needs to be involved when in a decision and some of the workflows that say in the instance we want to bring in a new data source for that. Do the standards exist? Is there a policy for sharing access that applies to the data source? Yes or no? If yes, do the standards exist and do they apply? Yes, continue on your development lifecycle. The policy doesn't exist or the standards you need them to be used. Now is the point at which I need to find since engage my data steward team. I know this sounds extremely simplistic but it is surprising how often we are not discreet enough about what to do and how to interact with other in the organization. That's really, really important because the extent to which we are not in really in a nutshell mandating to find that interaction is the extent to which the data governance becomes a volunteer activity. We're asking people to engage us on sort of different projects or different initiatives on their own personal beliefs in the topic or having extra time at hand. The extent to which the data governance of a volunteer activity is the extent to which it will not get done because when is the last time we actually had extra time on a project or even extra time on your day job to do something. So if the data governance becomes an as-time permit activity or is only as good as the ability of your stewards or your data managers to get helpful to help them out sometimes out of sympathy is the extent to which you're going to get traction long term. Secondary note here we talk a lot about managers and functions. To what extent do I need to have data stewards who are full of the job? What percentage of the time do my data governance council members need to be there? And there's not one necessarily answer for everybody because it does depend on the scope of your program and what people are finding. However, the one thing to know is that these roles need to be formalized with discrete performance metrics and measures around them and they may not be sort of the idea of a second day job. It can't be something that someone is just sort of already doing to give them the tag of a data steward or we're going to ask them to be on a data governance council or something that they do as an as-time permit. Okay? The person who does it because they feel the passion and the pain is sometimes a start and those are the folks that help us develop that grassroots movement but it is not a way for us to sustain that activity or ongoing data access. Okay. We talk here about being very clear about that we need to have people's responsibilities without providing the authority to actually make decisions and take action to make sure that accountability is clear and that we actually really define how this impacts existing roles and processes and ensure that data governance both in terms of roles but also in terms of participation in these practices and standards is into volunteer effort. And so, as I've said in mind and let's talk about a slightly different thing, I think that's very, very difficult and again, we see this a lot with organizations that are just getting started or have an organizational program start to grow. You have the idea that we are going to have a set of processes and practices and they are going to apply across all data or the domain across all of the different practices that we have with the organization. And so, it's a bit of an idea that we've got this sort of one-size-fits-all process. And the process is that it assumes that everything we're dealing with is both equally important and that everyone is equally prepared to engage in the conversation and in the solution. And yes, we know that's not true. And I'll use an idea. I was recently on a biking trip in Italy and somehow I had managed to forget that Italy was particularly chilly and also not experienced cyclists. When we were on this tour, we had very common goals. We all started at the same place every day and we all ended at the same place every day. And what was interesting is we actually had four different routes available to us. So those of us who were perhaps a little bit unprepared for a long route could take a shorter route. Maybe there were less hills. Maybe there were more stops. Maybe I pushed my bike up a hill or two. That's an advanced group that didn't need to do. But the idea was that we have a very similar policy or objective, but we have different mechanisms to engage. So one of the things that we need to be really cognizant of is are we developing flexible processes so that the assessment and level of effort that we're putting in place can be commensurate with the value of the activity or the value of the data that we're dealing with. An example here might be, for instance, the idea of data. I have a conversation for friends or the idea of data quality in big data. When we look at the traditional data domains, structured data, we approach for data quality. And data quality is still important to big and small data. It's important to all data. But now the systems might have changed a little bit. So this data very often, we're looking at that information. It might be that it's internal for the organization, and our approach is to identify those issues and to try to correct that at the source. It's a lot of times we're pulling sources from external places. They're third-party sources. We don't have the ability, particularly with social mediums and so on and so forth, to actually go out and correct that data. So if you find the issue and fix it approach, you have to actually to try to augment the data by providing multiple different sources that all together sort of, we can create a complete picture of a person, our business, et cetera, et cetera. This is sort of an augmentation versus a correct approach. Two different approaches to data quality, philosophically at the high level, are objective and outcomes are the same, applying a different process and practice. So we want to make sure that, again, it's all data quality issues are not equal. All data is not equal. And all the usages, all the context of use is not always equal. So we have processes that actually take that into account when we're deciding how to activate and operate against that data. And ultimately, the right to data governance or data management in the organization is the amount required to get it done. And we often, fall prey to this, again, as the programs are growing, we take a sort of approach that I call everyone for everything. As decisions or issues come up, we're pulling together or trying to bring everybody to the table to provide opinions and help to direct different issues and concerns. And what tends to happen here is either sort of this desk by meeting or this sort of committee consensus-driven for everybody. And in some organizations, this means that the data search approved so the data governance countable and the data debt block. We find the time to get everyone to the table. And then everybody needs to agree. And what ends up happening is we end up escalating everything to our executive team. So the data of issue escalation and exception handling be a standard operating procedure as opposed to an exception-based process. So the data is now dedicated or get acted on as an executive unit. And at this point, the executives are looking at each other and saying, hey, do I even have this program if I'm still required to make all of these level of decisions and very, very operational and tactical decisions that will allow, you know, to be the executive to pay grade. It's below what they're supposed to be doing. So we've actually seen organizations do this here. Okay? Both address the issue of what doesn't fit all, right? And every problem is not the same size and scale. We may not actually require the same level of activity to fix. But we're talking about working group-type mentality to determining who do we need to bring together to solve a particular problem. And we're talking about group mentality at the data stewardship level and so that's our data governance council level. When it comes in, we will take a look at it and say who is ultimately a general or needs to be an active part of this decision. And let's bring just those people to the room or into the meeting to address the issue. And then we move on to an agreement. Then we move on to the broader forum. Maybe that's the complete data stewardship working team. Or it's escort to the broader data governance council, the data governance council with the executive team to break that tie. But we're at any point in time going to be bringing together different subgroups or working groups of people to address a number of different issues. And if there's an area of interest or an area where you have decision rights, you don't need to actually participate. And so this helps the program become much more nimble and people are much more inclined to participate because we're not just all coming to a meeting where maybe we're talking about issues that nobody cares about or that we don't have an influence or a say in. Overall, the program is much more tangible, much more flexible and we're bringing people to the table as and when needed. Everyone for everything mentality. Another consider is the fact that we're not just talking about our approach, just speaking, our adverse to change. And the fact of the matter is that with data management, with data management, with more data control over data management, even with data management paradigm, we will be challenging existing programs. And we will actually potentially be actually an organization to rethink problems that those senior leaders actually put into place. So one of the things that we need to do is first be aware of us, be aware of change management incumbent in what we're doing and be very caught in how we communicate, how and why we're asking the organization to change. And what I want to say when I talk about cultural changes, we're not telling our executives and our business partners that baby is ugly. We're telling them that their baby is growing up and that they need to actually start interacting with that baby in a different way. So talking about the focus is on why now and what the expectations are. So we need to do the change within the organization at large. And we will very probably be challenging some existing operating models, existing roles, that's thrown up over time. But what we need to be aware of is that we need to make sure that we are future proofing our governance processes as well. I sort of had that idea of one-size-fits-all for that sort of everyone-for-everything mentality is that we actually understand up front that our data governance processes will change over time. Okay. Now I can talk to the organizations, and I say, if I come back in a year, so I do a lot of health checks, and the same people are sitting on your data governance council, we are not going to be wrong because either your business has not changed at all or the data governance council hasn't changed to match where the business is currently at. So we don't expect that our processes and the participation in counseling and processes will change. The focus is on a subject change, but the who and the what and the why will change over time. So as leaders of data governance, we actually have to make sure that we're setting expectations and we know that we might actually get it wrong. We know that we're going to come out in proof, might do a proof of concept or a prototype for a process, and we are going to adjust. We're going to have to make sure that it's optimal for the organization. And then we're going to put in place practices, so maybe it's a yearly review, or some new strategies are delivered. We'll continuously assess whether we have the right processes and the right people in place for the organization as it exists today. So again, two perspectives here with diversity to change. One is to understand that if you're going to data governance in your organization, even as much as we all agree that data doesn't asset, etc., etc., we'll agree to that to the extent it doesn't require us personally to change. We believe everyone else should change. We also need to make sure that we are actually addressing that issue in our program itself. And, you know, I was recently at a data governance console, and I was talking to a fellow in the financial, very large, global services institution, asking them about their program and how was it running. And he said, you know what, Dabli, it's great. It's fantastic. He said, well, all these, you know, we've gotten these new tools around data management and we have a process for data quality. And so, you know, people are coming in and they're asking questions. And I said, that's fantastic. So how do you decide what you do? What you want to do? How do you decide where you want to go to work with? And he said, well, Dabli, we're not informal. He said, it's really just about, you have to focus on the projects with people that I know and who know me and are willing to work with me. Right? So, in fact, there's a bit of a self-limitation here because that method works very good when we're just developing the program initially and finding some of those early adopters. But this is a mechanism that can fail across the organization in a large way. Okay? And one of the things I want to point out is that it's dependent on interpersonal relationships only that we're creating the sort of personality and relationship-led culture. And data governance is only as good as who you know and is only as good as long as those people remain in the organization. And again, the positions that they have. Okay? Using the knowledge it has a place. We don't have the knowledge to actually generate buzz. We use it to create some communities of interest. Right? In the process. But it cannot be the basis of running on-going engagement. Okay? So, we can actually figure out how do we actually create these roles and set these activities as well as into things like software development lifecycle in the process of developing business strategy. In the project of prioritization. To ensure that data governance becomes business as usual. Okay? And yes, there is a place for our ability to influence and engage the organization at large. So, this idea of interpersonal relationships will always come into play. The execution itself can't be based only on that. So, when we talk about the idea of data governance execution or some of the other things that we see very often is that when we go and talk to organizations we'll talk to them about what's the data governance program. Right? Any level. Whether it's executive counsel or the data counsel or the data stewards or the management teams are working on. And very often what they will tell us is, hey, we have this sort of working list. We have a whole number of projects that we started last year that we started here. We're starting to look at future projects for next year. And a lot of the projects got to a certain point and never sort of went any farther. And it's actually interesting because one of the things as the organization comes to the table of data is that there's going to be no dirt of putting your organization. Okay? You will not have a problem finding data issues to repair or dress or that need to be looked at. The question is, how do we actually turn those issues into executable projects and programs? Not only do some improvement but actually result in impacting the needle within the business. And there are some issues to be addressed here. One, you know, as we're looking at initiatives for data governance, data stewardship, data management, to what extent are those initiatives embedded or an integral part of other business or software development projects? The biggest indicators that we see is to the extent that data governance or data management projects are in a discrete effort and are baked in to ongoing business projects. There's a real technical indicator of where they will A get done and B in the long-term success will be. It will start changing the needle and changing how the business or the whole operate. So, again, when we're thinking about how do we execute and what projects should we engage on, the best place to start is by looking at our business strategy, by looking at those project plans and initiatives for our general basis, for instance, and figuring out how do we actually support and integrate within those projects. That's the number one best way to execute. The number two thing we have to look at though is that in some cases there may actually be projects that really are related to the data governance projects themselves. Maybe with the development of a new process and user-oriented policy. But it's going to apply across multiple business units, multiple processes. It's not something that necessarily can be done in the context of one discrete project or program. To define those, we need to be considering these things. The first is how do we provide these projects? How do we provide those the pipeline into the project prioritization and resource allocation pipeline? Those are the sanctioned funded projects. What's the second section of the point? And the second is under very often these types of projects, for instance, I need to actually re-evaluate our privacy and usage policies. We see a lot now with social media, et cetera, et cetera. We need to rethink our approach to data privacy and usage and access. Another interesting thing that happens here is there's two components. One is we need to create and design a new policy or provide data standards and data rules. And then we also need to implement those policy standards and rules. And then we're going to try to address those as one sort of discrete project stream. And the second is we may get down the path. We may actually create the policy and then there's a set of stops. We do have a clear plan for how we take that policy to market or how do we actually execute that in the course of daily business. And what happens is it's something that governments chicken and eggs. We don't have new policies and standards because systems and processes aren't going to be compliant with them. But our systems and processes aren't compliant or aren't adopting those new policies and standards. We don't have sanctioned policies and standards. Our policy here is this idea that we actually sort of achieve perfect compliance and achieve perfection in terms of the implementation of new policies and standards on day one. There are organizations that have done a really good job and they've made some pretty fundamental changes in how their organization and you know sizes around certain types of data or has changed their privacy and access policies in a tangible tactical way take a two-step approach. Number one, we need for new policies or data standards and data rules and those are going to be. And I think that initial project will actually to develop what the market or what the project execution plan will be. And that project execution plan which includes a phased role out when will different systems and processes have to be compliant when we implement this. Support and funding for that execution piece. And so if we do that way we can do something what I call creeping compliant. So we might have with new data rules new data standards new tools new projects and new projects come up we're going to ask them to actually adopt those things from the get-go. And as systems and processes are actually being maintained or upgraded we also ask them to then now make the changes to adopt maybe those policy standards or rules. So we start to get creeping clients from top from a bottom up approach within the organization. And it is to make very deliberate decisions about when and where new policies and rules will be added that will manage the pace of that change so that the organization can actually consume it. Okay. This is very very very important because it's very easy to come up with new standards it's easy to come up with new policies it's even easy to come up with better rules it's easy to then get those rules policies and standards implemented in practice within your organization. And the main is the extent to which organizations take an integral approach to that execution and implementation to the extent to the extent that they're focusing on incremental improvements and not overnight perfection is the extent to which these types of programs are successful or not. And then you know the least and those of you who have talked with me before seem to present I will admit up front to everyone else that this is my own personal it is that ultimately data data stewardship management is not about the data which seems particularly that data governance is not about the data but ultimately it really isn't because what we're trying to do here is to improve our data to drive the business so one of the things that we see happen very often for instance is that we might be focusing on and looking at and recording back to our executives and business leaders on how much better our data quality has gotten in an area and also they don't care they do not care because we haven't actually drawn the line between investment and data and investment in the business itself so one of the things that we need to actually be very very careful about and this overlays into both how do we prioritize projects but also we actually support out success but what is success and how do we communicate that we need to make sure we're tying anything that we do to to the business and that we really laser focus our efforts on those elements to help move the needle because there are a lot of data in the organization and they may be very painful to a large number of folks but there's a very discreet few I call it the 1% right the 1% the 1% of those issues will actually fundamentally move the needle for the business right it will help us improve the overall efficiency of the business or more effective and will help us lower risk so we need to identify where our focus areas and where our priorities are very very important to provide that lens and that will also report out those results in that context it's an example because it's probably an obvious one it's an easy one of financial services where we have a lot of for obvious reasons an idea of compliance like solvency and because as part of some of these new regulations we're to report on the completeness and accuracy of the data that went into for instance calculate our equity risk read in different areas and the regulators fundamentally care about how bad your data is actually trying to see is how bad your data is is an impater of how bad your business decision-making was or risk because your big decision on a risk number is one of the worst so one of the financial institutions have now started doing is now I report out my risk number maybe exactly maybe there's a whole list of issues but I also now report out what my confidence is in terms of the data quality like do you understand this decision maybe it's accurate maybe it's 75% accurate but based on that what I can say is I think I have a spread risk of this amount maybe it's 2 billion right but the data is 20% so I'm not sure of how accurate or correct it is but knowing that helps us really change the decision we make for instance right there's a different decision on that $2 billion number if I know that I got a 20% confidence in it I thought it was 100% confidence and what we're doing is tying data quality in this case to the business metric that actually has a fundamental impact that drives the bottom line now that connection between improved data with a big outcome and we can now make really smart decisions about when do we go in and start making decisions based on better what will influence our business decision making I think a very good one and a very strong tie-in between improving data and improving in business decision making and risk management so ultimately when we're talking about data governance when you're talking about your activities as a data board when you're talking about your activities as a data manager and you're talking about these things in terms of business impacts so data governance you know is hard to do and these are issues as I said that we see where their heads repeatedly of other organizations so checklists and this will be available to you as well as part of the PDF posted to this but you guys have to think about in helping your organization avoid the G board what's the DG for the plan so we'll really have a delivered approach and focus around what we work on and what we don't and how those new roles and processes will be brought to bear and we're going to take an approach of piloting roles and processes and being very clear and transparent with your organization that hey we need to do this we think this is the right way but we're going to try out in a very small focused area to roll it out more broadly so pilot proof of concept mode out work out the kings in these new processes and roles and then we'll create a blueprint that helps us roll out to the organization at large and it also addresses up front and sets an expectation of change over the long term you avoid that idea of second day jobs where people or data governance management is your second job is the extent to which that work does not get done on decision-making so we're not creating processes that are too common or too overbearing and we want to answer that the hurdles and thresholds for decision-making with these processes may relative to the sizing scope of the data we're dealing with okay which is that we do that because ultimately the best data governance is the most important that there is so right we only want as much data governance as needed to get a job done we want to push data governance and put it as close to the operating level where it's coming up as possible we need to embed these activities and decision points into our existing processes and we need to enforce that operational authority if we're going to see people that now have the ability to make these decisions we need to support them in that and we need to ensure that that proper escalation of issues doesn't become the de facto get a job free card right if mom says no I'll ask Dad to explain the extent to which we're undermining our own processes and practices so we have to practice this idea of positive promotion and again one of the keys here is that the way that we do that is by focusing on improvement considering ourselves and not perfection over over the long term and we need to actually measure business outcomes only one really cares necessarily about the integrity of the data if you can't align that to have a lack of integrity or lack of quality lack of availability or access is the day-to-day business at large okay and the last point here is that ultimately to that point your business should be driving your data governance strategy so the best way to develop your data governance roadmap is to look at business strategies which will have different initiatives and projects and then the question what is the new data new abilities or new tools are here to support those initiatives and develop the map based on that and for instance let's look at all the data in the organization and determine which is the data maybe the greatest value to the organization and vice versa with that and I'm in for some questions I'm already getting a lot of emails and comments about what a great presentation this has been thank you for that and just let me first of all for the most popular question that happens in all of the webinars and just let everybody know and reminder that I will be sending out a follow-up email with into business day so by end of Thursday with links to the slides and links to the recording of this session so you have all of that information and we've already got a couple of great questions coming in the question Kimberly you know I think you could probably turn into a full webinar itself let me just kind of throw this your way because you're covering some very important points there's two more things I'd like to hear from you one where going to be the trends of DG in near and far future and two which areas organizations are finding it difficult to perform because of lack of products and tools etc those very good questions you know it's actually interesting because one of the things I think that there's a couple of comments and that says this is really really hard and this is really really hard and there's an interesting balance here in terms of developing agile and responsive processes and balancing the organizations appetite for new roles and to some extent what's seen as bureaucratic process and that's I think probably the most important trends now this actually you know 15 years is that still there and I'm sure you all heard of it of this thing called the data officer and the organizations actually are instantiating chief data officers now is that they're realizing that this actually takes a libert and sustained approach to actually managing the change within the organization to changing our thinking to putting new processes and people in place and to make a course for managing that program from down so I think actually a very interesting harbinger of things to come because the extent to which we now see chief officer is the extent to which organizations are now not just talking to data as a conceptually but we're starting to put some resources and need behind actually developing that and of course the organization of the business you're looking at social and mobile or even just the idea of data monetization where we're more and more aware that the value in the organization very often is information the data we have more than necessarily and using that to drive products and services more than necessarily in the product or service itself so I think that's actually going to be interesting and that you know back ten years to the idea of when like stocks came into the competition when you looked at this is organizations like financial services where we have very rich processes for how we actually account for and report and so on and so forth and when stocks became into place every stocks project was a project in and of itself and every you know organization that was being developed or changed or business process being created that stocks applied with a sort of separate work stream for stocks in the organization and then we deal with our stocks content throughout built into those activities and processes and decision points are built into the business process development and software the CDO and this whole new focus on in the digital data sort of being that key a name for participating there and the increased around this and creating those role and processes that in 10 and 15 years we won't be talking about data governance as a discrete and separate thing it will just be part of business as usual whether that comes to push or not is you know a question but ultimately I think it's going to follow a similar as we saw with things like you know Sarbanes Oxley most organizations are still at a very early stage of that but we will we will see I think the second part of that question you said which areas or organizations are finding it difficult to perform because of products and tools and it's not organizations and I would say that's a lot of the larger organizations it's not necessarily a lack of products and tools except maybe around decision that don't tend to be there in your organization organizations have the flip side we have you know in terms of products and tools so it's not just standardizing our processes and you know coming up with the rules and the creation is the question of do we need to standardize on products and tools and which are those which are the right products and tools you know that's true for data quality data information math data management and what's sort of important to me is our approach to master data management our approach to data integration which in a lot of cases used to be much more about getting that into a centralized warehouse and then point it out and so on so forth are also changing radically but I would probably maybe controversially argue that organizations often find themselves more signing because the perfusion of data and disparate products then because of a fundamental lack of products outside of that business process management and decision management type workflow tools and in very as short as possible like I think you could probably do a whole webinar on those topics perfect the next question is could you explain the second day jobs point again and how that ties into assigning data stores without hiring more people and getting people to take more responsibility in addition to their regular duties so one of the ideas of the second job is the idea that well in a lot of cases we see this within you know where we're already integrating data we see this within our B.I. traditional B.I. analytics people are already maybe sort of doing the work of a data steward but we're doing that in an informal way because we fundamentally see the need and we're doing that but those folks are doing that in a informal thing and so it's sort of that idea we do actually need to develop room space for people to do that today and in many cases what's actually interesting is that we don't see necessarily net headcount in terms of people hiring into roles but we do see people hiring lead data stewards and there will be program management offices around data governance so there's maybe two headcounts around program management and external experience resources but well it's actually about formalizing the role and creating some metrics and measurements so that you're building people very standard eight hours for them to do some of this work but in some cases for certain organizations that's really just about formalizing things that people were often just right in self defense because they had to do it to get their job on or to make things easier for themselves but it actually does mean that we have to sort of develop some head space and it might actually have to reallocate other types of well it's interesting because we see a net amount of time actually there's some interesting case studies where we look at development project and studies have shown that probably up to 20 or 30 percent of the time any standard project has to do with you know just finding data trying to find it trying to integrate it trying to argue about whether or not all those sorts of things so there's an incredible amount of time and cost being generated and it's all under the covers right now so that's what we have to work with in the organizations has helped to make that case of here's the activities that you're not seen right now and you know bound against potentially the cost of increased head count you know time for addressing some of these activities that being said initially the best way to make that case is to start finding some projects and work on those projects not maybe necessarily with a formal data stewardship role but then as we create new policies or we come up with new standards and rules and new practices for the tools then we can make the case for formalizing that role and time to maintain that momentum so it's a little bit of let's prove it prove that it works improve that if we spend some time on these things there's a benefit or a bump maybe it's increased project efficiency and effectiveness maybe it's just an improved data and decision making coming out of that process and that's the case but the answer is not the same for everybody and it's probably one of the hardest things that we deal with because it's a very real cost to our data management and data stewardship and organizations that are buried into the day to day project work that we're doing time for just one last quick question here for you Kimberly and it's studies that helps sell and close the benefits of good DG or show the cost again cost of poor quality there's probably quite a list of those and probably depend on your organization to fill them off the top of my head but there's a couple of resources I think Dataversy is a very good place for those Gartner has some very interesting and Gartner reports around quantifying the although it's not sort of an act is what the DG does a lot of web professionals organization they sponsor a lot of available through that site that speak to that point and actually show not only how people approach it but what the specific value proposition was explicitly might be some of the areas that I might encourage people to look at and they can feel free if you'd like more information on that to ping me after and I can provide you a list of some resources so thank you and Kimberly if you want to send me some ideas and a follow-up email that goes out to everybody Thursday and again thank you so much for this great presentation and thanks to all of our attendees for continuing to be so engaged I know some of you were having a tough time and I apologize for that but it's just kind of it goes especially on the internet connections but you actually came through pretty clear that you missed a couple of words and things when listening to the internet connection you can link to the recording out to everybody again by the end of Thursday along with the slides and thank you so much for everybody hanging in there and thank you so much again for this presentation taking the time to share your wisdom with us I appreciate everyone for joining us and as we said if it was easy we'd be doing it Richard Ordwich you were providing some great feedback and comments as well and so do feel free to continue the discussion as and if folks are interested so thank you all and have a great day