 Hello and welcome. My name is Shannon Kemp, and I'm the Chief Digital Manager of Data Diversity. We are proud to produce this webinar series of data governance case studies for the Data Governance Professionals Organization. We would like to thank you for joining today's DGPO. How an organization leveraged the data deck concept to sustain data governance sponsored today by Calibra. Due to a large number of people who have attended these sessions, you will be muted during the webinar. For questions, we'll be collecting them by the Q&A section 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 DGPO. Now let me turn the webinar over to Anne from the Data Governance Professionals Organization to introduce today's webinar and give you a brief overview of the DGPO. Great. Thanks, Shannon. And thank you all for everyone who is joining us. We are super excited that you're a part of this. Before we get started with today's presentation, I want to give you a brief overview of what the DGPO is, the Data Governance Professionals Organization, and then I will introduce you to our sponsor, Calibra. So first of all, the DGPO is a community of data governance professionals, and our mission is to share knowledge, content, and best practices with our members to build a better community of practice. Towards that goal, we recognize six core areas that comprise data governance, and you'll see our core logo and graphic are down in the left-hand corner of this slide, and those six areas are fundamental, organization, process, metric, communication, and stewardship. As we share content like you'll find in today's webinar, you'll find that we are always looking to make sure that we are helping our members grow and develop in these six areas and to broaden our data governance knowledge and expertise. In addition to these informative webinars, there are also many other benefits being a DGPO member. To learn more, please visit our dgpo.org website. Now, just a little side note, I just heard that there might be some issues with that, so please, if you go and you see something that doesn't look right, we are working on it in the background, so please do visit as we make sure that comes back up and is online with no problem. With that said, before I introduce today's speakers, I'd like to turn it over to Dan Scholler for a word from our sponsor. Well, we're actually having issues getting Dan logged in, so, well, it was so... I know, so we want to do it. We want to do a quick and great shout out to Calibra for sponsoring today's webinar. He will be able to join us for the Q&A at the end, so we will just switch it right over to the presentation. Oh, okay. Well, then, I will introduce our presenters today, and like you said, I'm super excited to have Calibra as a sponsor, and I will look forward to them being a part... with Dan being a part of the Q&A as well. Super excited about today's presenters and to tell you about them, because not only have I had some fantastic experience working with both of these folks, but special to the GDPO for these guys is they are both advisors to the GDPO board, so they obviously are very highly recognized in the data governance field. They have probably forgotten more about data governance than most of us know, so you are in for a treat today. So, first of all, John Ladley is a business technology thought leader, and he's a recognized authority in all aspects of enterprise information management. He has 35 years of experience in planning, project management, improving IT organizations, and successful implementation of information systems, and he's the president of First Dan Francisco Partners. John is widely published, co-authoring a well-known data warehouse methodology and a trademark process for data strategy planning. He has books, Making EIM Work for Business, A Guide to Understanding Information as an Asset and Data Governance, How to Design, or excuse me, A Guide to Understanding Information as an Asset and Data Governance, How to Design, Deploy, and Sustain an Effective Data Governance Program. Both of those are recognized as authoritative sources in the EIM field. His information management experience is balanced between strategic technology planning, project management, and practical application with technology to business problems. And Gwen Thomas, who is a corporate data advocate for the International Finance Corporation, she is a data governance pioneer helping to define and analyze the evangelize of the field. Founder of the Data Governance Institute, which many of us are familiar, and a primary author of the framework and guidance materials found at www.dataggovernance.com, she has influenced hundreds of programs around the globe. In the spring of 2013, Gwen joined the International Finance Corporation, part of the World Bank Group, as their corporate data advocate. Earlier in her career, she was working in the trenches and in management roles as a systems integration consultant and knowledge manager. Informationmanagement.com has named her one of the 17 women in technology you should be following on Twitter. For what it's worth, she's at Cymbal, Gwen Thomas, GGI. Definitely follow her. There's lots of good information coming from her account all the time. And she's also included in the program. So with that said, I'm going to turn it over to John and Gwen for their fantastic webinar for today. Thanks, guys. Thank you very much, Ann. Hello, Gwen. Hello, everyone. I'll start here with some background on data debt. And then Gwen is going to spend a time telling her story about this. Well, let's just kind of get into things. First, this concept of data debt. Why do we need to talk about it? It came about as to all these things, necessity being the mother of invention because we still get asked for ROI for data governance and we try to do it even though philosophically, it's not the type of thing you do to rely on, but we give it a shot. Anyway, we still run into obstacles with all the business alignment and we just kind of started to think about there has to be a better way to sell data governance. And as you'll see here in a little while, we took a look at it from a when I started to use these terms several years ago, I took a look at it because that actually is my background a lot of people are surprised to hear that. Anyway, we put off data management and data governance a lot because we're not trying to deal with anything like that right now. And we all know that at the end of the day, that is a glib argument at best. Hey, John, I'm going to interrupt you just for a second. If you could speak up, some people on the webinar are having a hard time hearing you. Oh, really? Okay. There you go. There we go. Hold on a second here. All right. I think my microphone was under my caller. There we go. That's probably is that better? That is much better. Thank you. Okay. Sorry to interrupt, but thank you so much. No, that's fine. The next thing is issues of sustainability. We all know that we start these things in a year later. Well, we start them again. And then last, you know, how do we convey that data management is really important if the traditional ROI stuff doesn't seem to work. So this stuff does work. It's not a hypothesis. There's many, many examples in place. We're going to hear about one, one today, right? You know, it is, you know, you take two fictitious companies here, Sprockets and Coxwell Cogs, which I like to use because it, you know, as you get older you reflect on your childhood. And this is Saturday morning for me, right? Anyway, really good companies have a strategy in place. They align things with their goals. They align data management, data governance with their goals, and they're actively managing their risks with data management and data governance. And we are now in an era where there's dozens of cases and suitable examples of this. But we still have an awful lot of companies that just do things the way they've always done it. They try it, you know, we don't do it that way, or we don't do it here at this way, and they get and they let management get away with resistance and things like that. So the key thing here is not a hypothesis. This stuff works, right? It's how do we communicate it? How do we communicate that it works? We've been struggling with this for a good 20 years now in our industry. So there's a concept of data debt. Well, what is it? First of all, it's kind of two things. The first thing that I started it with is more of a metric. I consider it a way that you can unofficially on a non-balance sheet or notional or pro forma or whatever way you want to say it, measure what it's costing you to not do things right with your data. When an organization says, well, we really need to get better data quality because we take too long to gather data and correct it to do a report. What they're really saying is it's too expensive because time is money, but no one ever says how expensive it is. They just say it's taking too long. It's relativistic. Well, you can measure anything, right? So what is that measurement? So if you can impute what that cost really is and then you say, I keep spending that money over a period of time until I do something differently, I'll keep spending that money, which means I'm going to always owe something over time. Well, when you owe somebody money over time, that is called borrowing. So we're not making an entry in a data glossary and someone makes up a new word or a new term and we don't have it or there's an undocumented table put into that we have incurred a future expense. The other way, and we'll show some examples on how you get there in a minute, the other way here is it's a message. It is a very concise metaphor. You don't have to have a number, but you can say if we keep doing that, we're going to have to pay more in the future to unwind it. And that has turned out to be more powerful of the two aspects of this definition. I like the metrics I'm known for for doing a lot of metrics based on Gwen, as you'll hear shortly, was able to take the metaphor and the message and really evangelize with that and do some really, really neat things. So data debt is a way to express basically what any debt is you borrow against the future. So therefore it is a balance sheet type thing. For those of you that have been in technology and ran away from accounting classes, financial statements are actually pretty simple in concept. You have a balance sheet and you have an income statement and the balance sheet is made up of assets on one side and then has to balance with liability and equity on the other. And then, of course, there's the income statement, which is revenue expenses. But debt is a liability. That means you have to do something in the future. It's important enough to recognize it's a problem. Now we can have intangible debt on balance sheets. We don't have intangible data debt yet on balance sheet. But if we were to do that, that's where it would go. That is the type of number or metric or message we're talking about here with data debt as a metric. Now we incur this when we do have less than correct things around data. Now the concept of data debt comes from technical debt, which is a well-known concept in the agile development world. And it's pretty simple. If we have to defer a feature, the product manager says let's defer the feature, but what will it cost us on the next release to get the feature will cost more because you'll have to retrofit the architecture or the code perhaps. But everyone says yes, we agree to spend more money in the future to defer the feature. Well what we do with data is really no different. The inadvertent and reckless is when we do something that will be really expensive to do later. For example, we have a good customer master file from a CRM system from a few years back and someone doesn't like it or has a political issue, so they go out and buy a brand new master data management system and load customer into that too. You now have a future problem of having to put those two together. It is done with ignorance because it's usually done by one part of an organization that has obtained some political power, but it's not been educated to think about data. Then there's the deliberate and reckless type of activity. You know that's not the best way, but you feel like you've got to do ready, fire, aim and you just go ahead and do it anyway. I think that's where most organizations are now because everyone says we'll fix it later. We all know that later never can ever happen. It just never comes back around to happen. I guess another way to look at this is a topic I can explore later in a year maybe is data karma because you built some real bad data karma if you make these types of decisions. Now the third thing is we've learned from it and we are now getting smarter about it and people might bring to the table that we're really concerned that if we do this project it's going to create some data debt and you are being prudent about it and you're thinking about it but then you still go ahead and do it. You haven't really completed your knowledge about that. I don't think that happens very much. Of course the ideal situation is even if you do incur data debt you acknowledge it, you record it, you know the cost and you make an allowance to maybe take care of it in the future or you just accept it and management accepts the consequences. Now some of you out there are going well that's bad. It actually isn't bad. This is actually in my experience when we'll bring another experience here but in my experience what happens is an organization gets educated and that means educating leadership to a point where they know they're doing something incorrect and they are incurring data debt and they start to hesitate that or they start to allow for correcting it and it makes it more aware. Maybe it's just feeling guilty when they leave the office at the end of the day. I don't know but it is actually that is a good thing to happen. It's a negative asset. It is a liability. When you enter data into a spreadsheet instead of talking to your data management people and you departmentally do something or you're a data person listening to this webinar and you know of people doing this it's perfectly fair at this juncture and our level of knowledge should tell them you have recklessly obligated our organization to fix this in the future because you're building a mission spreadsheet. You have obligated us to some debt. That is a perfectly appropriate thing to say. If there's a perceived crisis then you think there's no time to design and you dive right in but in reality there's always time to do a little design right. That's just emotions entering into it. We learn our lessons when we have done something inadvertently then we take a prudent look and say we don't want to do that next time but the last thing the upper right hand corner is business conditions require that we incur the debt but we're going to figure out what we can tolerate and what we can't tolerate and make and take the steps to address that. Some symptoms on how this will arise here is cleaning up for data quality. Misaligned BI I think the BI misalignment if I were to measure when I've done metrics on this that's the biggest number I get. Most organizations have no idea what they spend on business intelligence. They say there's a budget for the data warehouse department or the analytics or the data scientists or whatever but they don't ever take into account a handful of business analysts and data analysts in every department the local tools, the local spend the time spent cleansing data and moving data around things like that. And when you add all those together it becomes a rather enormous number and you're obligated to pay that until you fix it. And some organizations actually have no idea that's so much money. They believe that is business as usual now and that really isn't the cost of not being able to count how many customers you have or products or what you've shipped just real simple counts because of data inconsistencies and that cost will continue and again if you have recurring costs over time you're basically incurring departmental accesses and spending in acquiring outside services external data sources all of those things. So you have ignorant selfish immature debt that's all bad karma and then you have acknowledged that you know at least we're going to do something when we deal with it in the future. The key here is that you are accumulating interest the longer you allow this to happen especially say well I can't do data governance or I can't do data management and we're still doing this and that's dumb but it's worse than that it's not just dumb it's getting really really really horribly expensive. I know of two organizations in the last three years of my practice that debt, data debt ground them down to the point where one declared bankruptcy and other one had to be acquired. They could not operate anymore. The data debt overwhelmed them. They didn't call it that but that's exactly what happened. So this is a message that a business will embrace even if we can't do the metric or take the time. This is a really good metric. Just a couple of scenarios to lock this down for everybody. Small company decides to assume risk around GDPR which is happening everywhere by now. May 25th has come and gone. I can guarantee you I've been in the room. Organizations have said well it's going to cost us 20 million to get compliant. We don't think the fines in our industry will be the full 4%. So even if it's 50 million yeah you know what we're going to take the risk or we're going to meet it in the middle half way. That's data debt. There are data scientists out there who just really want to run their model and they know the model isn't perfect. They run it anyway and then they say well it's not quite perfect but here's what you can use it for and people use it for it anyway. The model runs and runs and runs and it's a deficient model but it's still used in a less than optimal manner. A lot of you out there are in government in a common refrain that we all hear and Shannon and myself all that. I see that Dan is on now. He has heard this too. Good heavens I've worked with everybody on this call. Public entities themselves traditional ROI doesn't help with them but data debt is a powerful metric for a public entity because if you've got to spend something in the future to fix it, that's another budget. You are pre-allocating budget dollars that you don't want to allocate. You're putting yourself into a politically less political position that is not where you really want to be. Plus the cost of not doing anything becomes a real problem in those types of organizations as well. So at that point I am going to turn this over to Gwen Thomas and she's going to tell you a story of how this stuff works. Over to you, Gwen. Thank you, John. You don't need to stay on this page. They all know who I am. Great. Let me tell you our story. It actually started before we heard the term data debt and then continues from there. In our case, as John has said and by our, I mean the ISC which is the private sector arm of the World Bank Group. In our case the metaphor itself was powerful enough to become the tipping point for commitment to certain resources funding and actions of the type that are fairly universal. So I'm going to talk about those universal situations and how we were able to leverage this concept to get there. Our culture is one that if the case is strong enough anecdotally then it isn't always necessary to gather the metrics. So I'm not going to really be talking a lot about hard and fast metrics but more about how we use this concept to move our program forward. So I can only talk about up to five years ago because that's when I joined the ISC and at that point our organization just like most of the world was looking at their customer records. They were looking at capabilities that we had, excuse me and a decision had been made just about the time I came on board to start looking at MDM. Now, why were we looking at it? At this point again, we were not using the term dated debt but we did know that because of legacy systems, legacy processes, we had some duplicate records. Okay, us in the whole world, right? The technical teams weren't sure about how to source data because of this and some missing documentation. So that meant everything was more expensive, right? Everything took longer if we were working with our customer data and because these issues had not been resolved that meant that there were changes with certain analysis. The same sort of thing everyone has to do. What are obligations to certain clients? What are their obligations to us? If you have 17 versions of Citibank in Manhattan then that can make it a little bit challenging. Here's what became really interesting as we looked into why that had happened, why we were in the situation we were in. And it turns out that strong data quality controls had been built into the system that into which we entered our customer records. However, there was a performance issue so they were disabled and as John was saying we're always going to fix it right away, right? Well, they didn't get fixed right away. And so it became easy for staff who were entering customer records to create duplicates or to not have quality steps in place. So, let's see, John, on your one, two, three, four category here's one of the reasons we don't point backwards too much because we could get into a big debate whether that was reckless and inadvertent or reckless and deliberate about not including those controls. Whenever you have a situation like that, when there is an argument between the data experts and others, often it is because the consequences of actions are not communicated in a way that everyone can understand. So that's obviously what had happened to us low so many years ago. And as a result this analysis had been done and there was now an understanding that there were gaps in controls and there had been every project that dealt with this data took extra time, extra money, and because of lack of documentation about data, which is a type of data debt, additional inadvertent decisions were made so that there might be more duplicates, there might be missed opportunities to streamline. So we, just like a lot of the world, made the decision to undergo master data management program to clean up our customer data, standardize it, put governance around it, capture robust metadata definitions. This was a very important project for the company. It was considered central to many efforts. It cost way more than anyone wanted to spend on it, but the understanding was, well, we don't really have a choice. We spend it now or we can't do certain things that we want to do and the price tag will just go up. Boy, I wish that we had used the concept of data debt during those discussions. I wish I had been able to turn to the CIO and say, yes, of course RBI processors are too expensive because a simple report has to build in certain cleansing activities and you could consider that interest being paid on this previous project. So, in a way, this was our control situation. I could look at the teams and how they communicated with each other without this term and see where it was steady sailing to move forward and where we were. There was lack of understanding. Let's go to the next case study, John. Event slide. There we are. So, with generally the same players, a year or two later, we were looking at changing the way we did our data dictionaries and we actually had a robust glossary and it was pretty well used especially for business terms that were used in RBI environments and others but we didn't have as much technical metadata and we were looking for opportunities to put this all together. Having been through the debate with the customer master data, now we have some language to discuss why it was worthwhile to start to spend some money and give attention to updating something. It wasn't broken but it also wasn't adequate for future needs. So, leadership understood that projects took too long, we had added costs, mistakes are made, there's misunderstanding of the data but we weren't really quite at the tipping point for deciding to spend the money on this and then our CIO moved on to another executive rotation and we got a new CIO and she said, hmm, I don't know as much about working with data and governing data as I'd like to. Gwen and Jennifer, do you have any suggestions? And we said, what do you know? We're going to a data governance conference in New Jersey in a couple of weeks, why don't you come with us? Well, bless her, she cleared two and a half days from her schedule and came into this immersive experience with us. And one of the sessions was with Don, my friend John Lidley and in rather an offhand way just before he started talking he came over to where we were sitting, I got to introduce him and I asked him if there was something new he was talking about and he said, oh, the data, that's good and we shared another sentence or two about it and he stepped away to get ready. Well, my CIO turned to me and said, explain to me about this data debt. Now, it's wonderful, we're a financial institution. If you're in leadership here, you understand money. So I gave her the short version and she said what would that apply to? I said, well, we just spent amount of money on MDM to pay off a data debt because we did not put in a very simple set of controls because of performance and so instead of spending a small amount of money to fix the performance issues in the 15 years since then, we've been spending more than that every year as interest on not having quality data and to clean it up. We spent this huge amount and she said, oh, I get that. Oh, that's a good concept. I get that, I wish we'd been able to explain it that way. I said, okay, well, let me tell you about the next topic that's coming towards you and that is the glossary. So here is our situation and what, and you can imagine what having X but not having Y does to the cost of resources when we have to do the following types of work. She says, oh, you mean they don't have a technical dictionary with to do this. I said, well, this is before my time, but I was told we had it at one time and something happened that it went away, I don't know, a couple of contract firms ago, so I couldn't speak to that, but the shorter answer is no, we don't have it. So you could say we've been paying a lot of interest, a lot of data debt on not having that. She turned to me and made the most adorable face and said, oh, my gosh, Gwen, are we data bankrupt? And Jennifer and I laughed and said, no, no, we are not bankrupt, but we have been paying a lot of debt on this. So we're hoping that under your tenure as CIO we'll be able to start paying down that debt and perhaps avoiding future debt. She said, okay, we're going back and on Monday I am going to issue instructions to all of my management team. When it comes to data definitions, we're going to talk about new data debt. Period. I said, oh, that's fantastic. Thank you. She said, well, it only makes sense. So we're going to say that a project is not complete until all of the terms make it into the dictionary. And if you have a project that works with data, we expect you to go through the dictionary. And if there's any existing debt, I want you to pay it down. Build it into your project plan. I said, okay, great, you know, you're going to get some push back on this, but I think that's the right thing to do and I'm grateful for it. And she said, good, good, because I'm not going to back down on it. And I sat in meetings with people and I said, okay, you're going to get a new cost. It's that you under budgeted to do this work. So this was, what, three and a half years ago. And the no new data debt ruling has absolutely stood since then. And it gave us a way of discussing the situation without throwing out getting into the was it deliberate or was it inadvertent, who knew what, who made what decisions. We could just say, all right, the fact is the debt exists. And then she said, okay, so we now are going to have data debt discussions included in our annual planning. So every project that comes through, Gwen, I want you to ask them, can you ask a handful of questions that would indicate whether they are taking debt into account? And I said, oh, yes, yes, we can. So the data team got involved in not only annual planning where we would look at whether data is being appropriately treated in the capital budget and one-time admin, but also pointing out the impact on future maintenance costs. We also got a seat at the table for reviewing all projects that go through the IT governance process to actually kick off the projects and get the funding that had been given to them. Now I have to say this absolutely falls under the category of be careful what you wish for. That work is that's something that everyone should have to do sometime in their life, in their data career. Just like everyone should work fast food so you understand how it goes. But it's it was not as much fun as some of the other stuff. But you know what was fun? As we were discussing throughout all of our processes now, what about the data? What about the data? Now we were able to introduce just good solid data management and governance discussions with the audiences that might not have been included in them otherwise. We could say what are you doing about ensuring the quality? What are you doing about controls? What are you doing about this or that and the other? And if we got pushback the answer would be you don't really get to pushback on security. There are certain things you can't opt out of and our CIO has decided that there are certain data you can't just opt out of either. So that led us to deeper and richer conversations and planning and strategy. And a theme kept coming up and that had to do with access control, access government, access management if you would move the slide. So we discovered that not only did we have some natural inevitable data debt in this other area, but we, just like most of the world, we're going to have to move into a new house. We had to get a bigger place. Sometimes the existing structures just aren't adequate for what's coming forward if you're dealing with privacy, if you're dealing with especially in our case, changes in our business model. Many of our systems, and again I'm not saying anything out of school here, but many of our systems are older ones were built under the assumption that we would have almost entirely internal workforce, very few consultants or contractors, therefore if you made it into the system, then chances are professional discipline would be strong enough for what you could view, what you could act on, and perhaps I didn't need to prevent you from taking certain actions. You knew it wasn't your job to do that. So we were okay. But with changes in business models comes the need to expand who can see what and we really, really needed some fine grain access. So we started exploring what our options were and this is this amazing effort I'm in up to my ears with right now we decided to leapfrog several generations and do some really strong cutting edge stuff. And so in our case this concept was so necessary to describe that because when we would talk about the activities that needed to be done and the cost and the attention that would take to it we were able to divide into well this is existing data debt. You know, everyone knows you have to have groups of people and group management but come on guys there's this last little piece that's still in Lotus Notes. Hello, we got to move away from that. Okay, so that's paying down an existing data debt. But then we also want to take on these brand new capabilities that we didn't have before. Oh, that's a new mortgage. All right. So we were able to break down an extremely complicated work program in a way that would allow the various teams that would work together and take on some of this burden to understand what role they were playing. And quite frankly I'm not sure that we would have been able to move forward with this complicated an effort if we had not gotten the seat at the table before trained people to start thinking about what's going through the pipes and the pumps and the filters and not just the technology that is those pipes and pumps and frankly the term data debt just really, really helps us sell it. So that's sort of an evolution from our perspective of how just a metaphor can really help us work within our unique culture and our unique environment to bring labels to work that non-technical staff and even sometimes technical staff wouldn't really understand. We could say, okay, well for this effort about a third of it is paying down existing data debt about a third of it is updating our rules and about a third of it is taking out this mortgage for our new capabilities which come along with the promise of using good data practices to not invoke future data debt with that. So did you have some other words you wanted to say John about this before we took questions? I'm just going to just wrap up. We've done some here's a quantitative example when Mary eloquently talks about the messaging is powerful but you can do this pretty easily. Here's some real quick things here. Just someone wants to do some funding in some other area and another division wants to do something that might help the same way and the CIO wants to do something like that and everyone defers the CIO doing data governance and data management to synchronize up the other two projects and so you kick the side of that study and it's just really easy to say you've just at least minimally put $1.5 million against the future. So there's that then. The real key here is how do you defend what you're doing with data governance what you're doing with EIM and we always get these questions we need better data just get started give us all the data who hasn't heard you know data scientists don't need data management and we still hear that occasionally where they say look you know our algorithms will be superb and will overcome all data issues which is not correct. Business gets all the benefits IT is a service so you really don't have any say in all this. All of this this is a way to respond to all of those now that we've been struggling for for years and years and years. At that point we can now go through our questions and answers and we'll turn it over to you now and I'm unmuted Gwen's unmuted we can get Daniel in on this and we'll go from there. We have a lot of questions coming in it looks like. We do. We've had a ton of questions so are we okay to just jump right into them? Sound good? All right. John you talked about two companies that you know that struggled with data bank reps and this person is looking specifically are they simple and easy to understand public stories that demonstrate the importance of data governance and following on they kind of said Cambridge Analytica was one that was kind of an obvious one so do you have any that or something you would suggest them to kind of turn to to look at that kind of obvious? The Cambridge Analytics is really focuses on what Gwen's working on now and that's the related to privacy and security and ethical uses of data and that's a whole brand new form of data that says I hadn't even considered when I started to talk about this three or four years ago. So that's a whole that's a new one. I would say if you companies don't publicly admit this but if you take a look at the insurance company or bank that in the last recession which was the two seven 2008 recession went under because they didn't have an awareness of their exposure I can say one of the really large investment houses that went bankrupt as soon as the derivative thing hit bottom and I forget their name for some reason right now they've actually been asked to propose a system to track derivatives for them and we pitched it and we told them it was the company I was working with at the time it was 14 or 15 million dollars for a small data management system with data governance to control all of these all this derivative data coming in and it was 5 million in the tech and 10 million of data governance and procedural changes and they exploded they said it's far too much money we're doing it on spreadsheets that will be perfectly adequate for now and three months later the world was different on a Monday morning when this company collapsed over the weekend so there's one specifically that you can look up a public name and it was entirely tied to data absolutely 100 percent was data most of the recession was the fault of bad data management so there's a lot of public examples out there I also recommend Doug Laney's book Infonomics he has several good examples in that book as well that are public as well okay and I think you're still on point of it's not even it's not all data solved right there's some of those a lot of that's the policy people and procedure that's around it and you guys note two I'm not going to hit everything that's in chat because there's a lot of good information flowing around in the chat far as well but since that's participant kind of going back and forth if you guys want to pay attention to what they're saying but I want to hit some more of these questions that you guys have asked as well so I'm going to move on to the next one which is do you have actual dollar figures that you calculated for the debt or would you say it's more qualitative or all qualitative so in our case it was qualitative but different cultures are different so John you could answer that and we have a request for you to go back a slide if you don't mind doing that back a slide that one yep okay you can do that yeah this is all kind of rationale for using the concept of data debt here mostly it's we a state of people when we get pegged into a corner by an executive we fold and run because we're just not trained up to that it's no deficiency on our part but now you've got something so stick your chest out put your chin up and tell them data debt anyway to answer the question quantitative things I have done it on a pro forma for a number of companies just as an experiment to see what numbers we came up with for example we had one company where there was a product they had to massage product data they had they had a product master file which was okay but then they brought up a website because they went into e-commerce a little late in the game they did it on themselves they did it themselves or they pushed it to a service and they didn't push very good quality data out and their website was horrible so then they hired a bunch of people to manually correct the data every night well okay as long as those people are working and you are manually changing the names of products or manually changing the unit of measures or the stock keeping unit number you could fix that right so every year you pay the money is money that you're borrowing against the future so that is the amount of debt we said you can fix that or you can pay this up to you they elected to go ahead with the different product information management system to fix that but sometimes you do make the decision to continue as you are and it's just useful to make an informed decision absolutely that's the other thing a lot of people they give up they just say well we can't do data governance this year we can't do it this year and they go darn and then well no I say fine let's just record what we're still spending on this stuff and then next year when it's time for strategic planning and all I'm gonna say now last year we didn't do this in the meantime we spent this much money on fixing bad invoices for customers we spent this much money on doing this and we will continue to do that and if I do a net present value I know that's a financial number but that's a metric a net present so if I do a net present value of that outflow of cash now for the next five years and I take my internal rate of return and some of you have glazed over I'm sorry but that is the amount of the debt and that is a bona fide financial analytical number right there we've done that a few times too but then you say or you can continue to just borrow the money look we all borrow money I want that car now twice as much for the car as the showroom price but we want it now and maybe someone needs to do that but at least you know what you're spending that is spot on Glenn and is probably a premier use of this concept and I think it's useful for us to point out that we've been moving back and forth in this conversation between data management strategy and accounting and data governance in the case of some of our control deficiencies or old technologies maybe that's just data management and we've got debt with that in some of the cases that lead to data disasters it's really a governance deficiency in mind that governance starts with decision rights who gets to make the decision so you could manage your data the best in the world but if you have made a decision to use faulty models then that is a governance decision that's going to have impact so I know in some organizations there appears to be a very clear line of demarcation between governance activities and data management activities and even technical and data strategy activities but at a certain point you have to look at this holistically I thought I heard maybe Dan trying to play in here I had sort of this is Dan Scholler with Calibra by the way we're happy to sponsor this webinar I'm so glad you guys can join us I just wanted to one of the things you just touched on which I thought was interesting was you said data management and data governance I guess coming from an IT background like I do I think of that first thing as an aspect of technical debt and there's a lot of strategy that people have had about how to manage technical debt in terms of allocating the bottom line is you wind up having to allocate some money every year to retire some of your debt you're not going to do it all at once but you're going to keep making decisions about what to retire and keep moving it forward I think what we've observed with a lot of organizations is the way that the governance part of that is done doesn't have that there's no IT budget to allocate money from you know it's something that's done kind of on an ad hoc basis different projects or different initiatives come off the ground and so that's probably I would imagine I mean Gwen you can tell me if it's correct but I imagine that might have been the more challenging part is when you figure out where are we falling down we may figure out that it's in the technology that we're doing we're storing that stuff in Lotus Notes as you've said that one I think we can get our arms around how do you deal with it with that I hope and pray that auditing firms take a close look at how they categorize data work because when it's always categorized as admin instead of capitalizable it ties a lot of hands and sorry to anyone whose eyes placed over there but the point here is every organization has different buckets of money and there's an awful lot of not me hot potatoes going with around with the data cleanup work you know I'm going to use that as a segue to another question just because there's a ton of questions we're not going to get to and hopefully we'll be able to have a chance for you guys to follow on with these questions but a lot of these are very related but there's one that kind of stands out that we see a lot in other topics and is the who piece of this and so it's not just about the who's going to do the cleanup but this particular question is who should own this data balance sheet should it be finance should it be IT who do you guys think should have this ownership I'll defer to the accountant data governance this is business alignment and data governance is one of the key capabilities I feel in the data governance area is business alignment and that means helping the business keep its balance sheet clean whether it's pro forma or real I'll stand the way in here Dan have you any thoughts on that one that's where I think it should go but maybe you've seen in your business and you know do you have as a provider of product and service maybe you've seen something different well it's interesting yeah I think the answer is exactly what you said obviously the challenge industry-wide is that the ownership of data governance is not always clear right you know if there is a data owning organization like a chief data officer then it often resides there but even that you know there are activities around governing the data that you know for example the marketing organization may think they own about governing you know prospect customer data for example or things like that and that's where you know that's where the clearly there needs to be a central point where you consolidate all of that information to get a view of what your debt is and what the opportunity cost is I mean that's the other piece of this right you know it's the same way that you have with like you know if you have too many credit card bills you can't go out and buy that new car you know if you have a lot of debt going on then you can't use the data to create new value because you just don't have the resources and I think that's the you know to be able to draw that picture even if it's not you know down to the penny you know that's a tremendously powerful tool and it's got to be done on a large in a large enough scope that people can understand it so you know where we've seen it done where organizations have done this kind of thing effectively generally there has been some piece of the organization whose primary job responsibility is to make sure that we they get value out of their data whether that's a chief data officer or something else and those are the people who own that concept of the value of the data and the debt associated with using it. Okay Shannon I know that we are right at the top of the hour so there's some other great questions but I don't know that we really have time to address them here I think I need to pass it back to you at this point. Thank you Ann and thank you John and Gwen for this great presentation and thank you Dan and thanks to Clebra for sponsoring today's webinar. Just a reminder that the recording and the slides will be published to the DGPL members only section of their website and within the next week. Thanks everybody for being so engaged in everything we do and thanks for tuning the webinar we hope to see you in the next webinar next month. Thanks all. Thank you all. Bye bye.