 And hello and welcome, everyone. I'm Dia, and I'm the webinar function of the State of Berkeley. We would like to thank you for joining today's State of Berkeley webinar. I'm exercising the Seven Deadly Data Sense. So, yeah, exercising the Seven Deadly Data Sense, it's the latest installment in a monthly series called Data Ed Online with Dr. Peter Akin. Here's a couple of points that have started. Do the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A in the bottom right-hand corner of your screen, or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag data ed. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom middle for that feature. And to answer the most commonly asked questions, as always, we will send a follow-up email to all registrants within two business days containing links to the slides. And yes, we are recording and will likewise send a link to the recording of the session as well as any additional information requested throughout the webinar. Now, let me introduce you to our speaker for today, Dr. Peter Akin. Peter Akin is an internationally recognized Data Management Thought Leader. Many of you already know him, or I've seen him at conferences worldwide. He has more than 30 years of experience and has received many awards versus outstanding contributions to the profession. He has written dozens of articles and 11 books. The most recent is Your Data Strategy. Peter is experienced with more than 500 data management practices in 20 countries and is consistently named as a top data management expert. Some of the most important and largest organizations of the world have sought out his expertise Peter has spent multi-year immersions with groups as diverse as the U.S. Department of Defense, Deutsche Bank, Nokia, Wells Fargo, the Commonwealth of Virginia, and Walmart. And with that, let me turn everything over to Peter to get today's webinar started. Hello, and welcome Peter. Hi, Paul, and thank you for a very nice introduction and a happy holidays to you. Happy holidays to everybody here. I hope it wasn't too early for some Christmas music, but that Tom Mason album is one of my favorites that's there. I do want to clarify one thing that Paul said on here. He said exercising, and actually the word exercising is what most people do. What we want to do with this presentation, of course, is exorcise these things. So exercising is where most people are, and we want to change that from exorcise to exorcise around that whole process. So when we look at what's happening in the area of data, it's kind of interesting. I call this my most profound lesson so far, and most of you know this as well. It means garbage in, garbage out. And so I've built essentially the practice around that, saying that no matter what you get, if you've got bad data, it's still not going to be helpful. And we call this, of course, G-I-G-O, or garbage in and garbage out. And of course, the higher lesson to this is that if we have data that is imperfect in any way, perfect in any way, shape, or form, and couple that with a perfect model of some sort, we're still going to end up with imperfect results. And that is true whether you have a data warehouse, whether you are doing machine learning, business intelligence, blockchain, AI, data governance, MDM, analytics, any sort of technology. And the part that I think most of our managers don't quite get yet, is that we're trying to do this oftentimes in multiple streams from the same base data cluster, and that can be extremely disruptive. Only if we change that garbage data to quality data, then we have the opportunity to look and perhaps even eliminate some streams here. I've gone into some companies where they're running the same thing into two different pipelines, and we can smooth out those whole processes. Because once you get data that is good, then on only then can you start to get what we call good results from this. And I like to say quality and quality out around that whole process as well. So today what we're going to talk about are what I've called the seven deadly data sins. And it would be wonderful if it was just as simple as pride, and degree, and hatred, selfishness, et cetera, et cetera, but instead they go a little bit differently. Let's jump right in. The first deadly sin in data is failing to address cultural and change management challenges that are around data. There's still unfortunately much confusion, even though we've been doing data, and many of us have been doing data for multiple decades at this point, but IT still in general thinks that data is a business problem. And they look to things and say, well, if they can connect to the server, then my job is done. I don't really need to worry about what the contents of this business problem. Meanwhile, on the other side, we have business thinking that IT is managing data adequately. After all, what is the title of the person who leads the IT function? It's called a chief information officer. What else would that individual do and who else would be taking care of it? As a result, data has fallen into an enormous chasm that we have had to deal with for years and years. This is what I call data debt, bad practices causing things to go worse and worse. Our goal, of course, with all of this is to repair that damage, work a cooperative relationship back in place with business and IT, and collectively, let's go on and achieve the objectives of the organization, whether you are a government organization or a private company. Now, people like me have been out there doing things that have been stirring this pot, and I often use this title here. I was going to use this as the title for the book that I'm going to show you in just a little bit, which is a very, very provocative title that says CIOs are not, or CIOs are really labeled incorrectly. Of course, we know that labeling things incorrectly leads to data problems. They wouldn't let me call the book that, so I had to call it the case for the chief data officer. If you're interested in these and some of the other titles are on sale today at my website, you'll see the directions on how to get that as well. Interestingly though, when I had this book translated into Chinese, it came out with a very interesting title. The Chinese read the book and said the book should really be titled Chief Data Officer Combat, and I don't mean to make it quite as provocative of that, but now what we're doing is we're saying we have organizations that have chief information officers and chief data officers, and as we know, many people have the trouble, have all sorts of trouble telling the difference between the two. So consequently, how these two will work in harmony together is a big source of consternation with many organizations. In fact, our colleague, Mario Faria, has put out an article that you can go read out there. It still captures everything very well. It just says that if we start having CIOs and CTOs, they're bound to be confusion, uncertainty, doubt, resentment, and resistance in all of those areas. And chief data officers have their own tasks out for them, but more importantly, the organizations as a whole need to pay attention to something that many of them have experience with but don't think applies in this case. And that is the discipline of change management and leadership. If you have a change management leadership group in there, I would urge you to go talk to them as soon as possible about the types of things that you're encountering in your organizations, because they are really a hearts and minds battle, and I'll show you how that comes about in a little bit. In fact, our colleague, Mary Lippert put together this wonderful little diagram that we use when we talk to various organizations. For example, if I walk into one of them, I see that there's vision and skills and incentive and an action plan, I will also likely see frustration and the reason I will see that is because that group is lacking resources. On the other hand, if I see a vision incentive, resources and an action plan, but no skills, I'll see anxiety. So the column on the right there is what tells us what the symptom is. And only when we have all five of these things, vision, skills, incentive, resources, and an action plan do we actually get change. And that is a very difficult task for most organizations. And if you've been in the business at all, you know that culture is the biggest impediment to shifting organizational thinking in data. So this is our first bit here that we really need to pay attention to on the and the idea again here is that we need to make sure that we are paying very strict attention to change management and organizational leadership. If you have other areas that you're interested in, or this is a new topic for you, I have a free no registration note download case study that you can put on this. I put it in an academic journal a couple of years back so that everybody could have access to it. So that's our first data send. And it's a deadly data send that you do everything else right and forget to address the cultural and change management aspects of it. Your data initiative will achieve fewer results than you'd like it to. The second deadly send, notice I'm coming backwards here by the way guys, is not implementing their data strategy according to sequences. Now, when I say sequences, it's important to understand here. So I'm going to give you a couple of examples. First of all, hopefully most of you are not seeing this representation of the data management body of knowledge version two for the first time. That would be an unfortunate if it is, but if it is the case, I'm glad to introduce it to you here. This is what we mean when we say data management. And unfortunately for this, I'm the past president and I'll be the next president of DAMA as well. I'll start in January for my second term around this. The idea is that many people look at this logo that we have infographics and say, oh okay, DAMA says I must do document and content management or I've highlighted metadata management here if I'm going to do data. Now, remember, sequencing is what we're talking about here. And the idea is no, this graphic should really show things to you in a progression and that progression should be along the lines of there's some things that you need to do first and some things that you need to do second and possibly third and all the rest of them. So even our guidance to the community can use some improvement here in terms of sequencing. I would never advise most organizations to start out with a technical area like metadata management, but there are certain circumstances where it can be done. So this is an example of the strategic sequencing that I'm talking about. I'm going to give you another example here. This is where I'm calling you from today. This is my house in Montpelier, Virginia. I live at a place that has internet capabilities where I'm uploading this presentation here to you on a 0.3 megabit connection and it still works. Now I'm not showing you my house because I love with it, although I do love my place where I live, but instead I'm showing you a barn or at least a semblance of a barn that I produced. Now those of you that don't know me more directly, I'm what's called a horse husband. And so building a barn was part of the process when my wife and I got together 16 years ago and started doing this. Now I'm showing you this because it's another example of enforced sequencing. I borrowed money from the bank to build the barn. The bank gave me exactly as much money as it takes to put in the foundation. Then they stopped and said before further construction can proceed, we need to have a foundation inspection. The lead for this is very simple from the bank's perspective. If I have money and I have built a good barn on a poor foundation, I'm going to spend money in vet bills fixing things that happen before I'm going to pay off the bank loan. So the bank wants to ensure to the best it can that the barn is built on a good foundation. Of course you see where I'm going with this. Most of our organizations do not have a similar step where they look at the data foundation for anything that IT is doing and say do we have a good solid foundation in place on which to build the rest of these initiatives. So this is what I mean by enforced sequencing here. You've got to have a data foundation in place before you go to the next step. Some of you, a third example here, some of you may remember Maslow's hierarchy of needs. Yes, it relates to data here, so let's see how it works. First of all, Maslow said back in the 50s that if you have food, clothing, and shelter needs that are unmet, then that will prevent you from reaching the next level in Maslow's hierarchy of needs which is becoming safe. So if you have food, clothing, and shelter needs, you will never be safe. If you have safety needs, then you will never be able to have love and belonging becoming part of something that is larger than yourself. And if you have, of course, no ability to become larger than yourself because you're not safe, then you will never get to figuring out what your role is within that larger organization. This is the role of self-esteem. And finally, of course, we get up to self-actualization. And a lot of people call this now flow. You'll see there's all sorts of TED talks out there around this as well. And what does this have to do with data? Well, it turns out that data isn't awful a lot like that. Everything that is spun up about is the popular press outside of the Dataversity umbrella that we work in here. You will see these people are out there saying, you need to go straight to self-actualization and do your student data management or data mining or bit chain and sorry, block coin and bit chain. There we go. I'll go backwards there. And none of that is possible. And more importantly, these things are technologies. We need to understand that this is just the tip of the iceberg that's there. And that we need also to put in place foundational data management practices. In this case, we're going to call them governance, quality, strategy, platform and architecture and operations. And these five practice areas are required before you start doing anything up in the technology area. There's another reason for this as well. And that is that these are capabilities for an organization. And these capabilities are things that your people possess the ideas how to do, the knowledge and the skills in order to do this. If you're trying to build a data mining program and you have foundational data practices that are not in good shape, you will have problems with them. In fact, that's the most frequent question that we get at the regular telephone line that rings. People say, well, I got it, Peter. I understand the top part is the visible part of it and the bottom part of it. But if we do it faster and we don't understand it, can you do it faster? And the answer is yes, we can do it faster. But if we do it faster, it will take longer. If we do it faster, it will cost more. If we do it faster, it will deliver less. And if we do it faster, it will present greater risk to the organization. Then if instead we walk, crawl, excuse me, crawl, walk and run our way back up to the top of the pyramid. So again, another example of data strategy perspective. Another example here very briefly is to take a quick look at what we've got here in terms of a generalized strategy pyramid. Now, most strategy focuses in on two areas. The first one is to improve your existing operations. The alternative to that is innovation. By the way, there are no other ways of doing this. One or the other. We've been over this a long, long time. So of course most of you don't want to be in quadrant V1. Those are organizations without a formal approach to this. And many people then say, well, I'd like to improve operations and that makes good sense. Walmart, an organization I've spent a number of years with, has probably some of the best people who are able to increase organizational efficiency and effectiveness in the world. This is one of the things that this company excels at. And I want you to look at quadrant V3 here now and pretend that Apple actually makes really innovative products. Now, don't get me wrong, I'm an Apple loyalist for many, many years, but we also know part of what Apple does is it sits back and watches everybody else make mistakes and learns from them. Now, here's the point. Don't try to do both of these at once. And yet we see this happen over and over again where people go, data, cool. I want to do all sorts of really good things with data and they'll try to do both V3 and V2 at the same time. Again, from our sequencing perspective, it is much better to start off with your ability to increase effectiveness and efficiency and use the savings from that to fund your innovation activities. If that doesn't make sense, hit me up in the Q&A section and we'll come back to that. But the key here is that most organizations try to do both at once and you shouldn't do that. It doesn't work. In fact, I want you to just do a thought experiment here and take the really effective guys who are, let's see, Johnny Ive would be a person at Apple. He used to work for Apple, one of the designers. He's the very bright British guy that comes on and tells you about the wonders of the new iPhones and all these things while the iPhone is spinning in front of you on the various advertisements and things that they do. And I want you to imagine telling Johnny Ive that he's got to be cheap. It's just not going to work. Or I want you to go to the Walmart guys back in quadrant V2 and say to the Walmart guys, I want you guys to be innovative. Well, guess what? They've been doing efficiency and effectiveness for the last 10 years. They're not easily going to go into that innovation space. So again, the example here of the second deadly thing that we're talking about here is that your data strategy should be focused on either improving operations or innovations. And unless there's some particular reason that you should, my suggestion would be to start off with the innovation. Excuse me, start off with the efficiency and effectiveness pieces so that you can then have those savings concrete and then use them in the innovations in there. Give another sequencing aspect here. Motivations for doing more with data. First of all, organizations like to do things with data because data points to where valuable things are. Data has intrinsic value by itself and it has inherent combinatorial value in a very, very, very strong way. That's why everybody wants to do it. But if you get your data better, you still have a second piece that you need to deal with, which is that you need to improve the way your people use its data. This is the big push around data literacy that we're all experiencing today. And I hope to have a book out on that in the first quarter of next year talking about really how to save knowledge workers a lot of productivity time by getting them more data literate. Again, you want people to understand the way to use data because you use data to measure change. You use data to manage change. You use data to motivate change. And yet for some reason people will think that they can just improve their data without actually improving the way that people work. Finally, once you have both your data and your people skilled up and your data cleaned up, now you can start to do a competitive advantage play. And this is the innovation that we were talking about before. And I'm going to talk a little bit about Rolls-Royce because they have a great story here. Now Rolls-Royce engines division used to sell things to airlines. The things they sold to airlines were the jet engines. And in general, the jet engines worked. We've had one failure in the jet engine that caused a human death in the United States in the last 10 years. That is an astounding track record. And yet Rolls-Royce wasn't happy with that. They sold what were considered to be the best jet engines to all of the airlines. And they said, no, we have to make a new business model around this. And they had to change their company from a product company where I sell you the thing, the engine, to a services company. And the service that they were now selling is hours of powered thrust. They even had a catchy name for it. It was called power by the hour. Now, the reason that Rolls-Royce was very, very interested in changing from a product company to a services company. And by the way, that is one of the hardest changes any company can try to go through. They wanted to have conversations with their customers. The customers of these jet engines were not terribly interested in talking to them. It was just, give me the jet engine and I'll put it on the plane and everything is fine, right? Well, it turns out that Rolls-Royce actually wanted to have some conversations with the jet engine customers. And one of the conversations they wanted to have was something that they were learning from formula one. And the idea is very, very simple. We look at how things are going in formula one. Rolls-Royce comes in for a tip stop time to refuel and change the tires. Lever and valve changes the tires. Only four crew members including the driver are allowed to work on the car. That's not it. Baze in a seat. Thank you for getting away. Let's watch. The tires are changed to glass. A crewman promises to win field as Rolls-Royce will be back in battery stop. Okay, so here's our first measure. Two tires. Quick enough. I'm supposed to say two tires in 64 seconds. Now, of course, you see that the new measure is four tires in four seconds. Management pays attention to those improvements. And that's one of the things we have to show. This initiated the process of what Rolls-Royce really wanted to talk to the airlines about. Something called wing wing. In other words, if there was an engine failure on a plane, not while it's flying but needed to be maintained, when you come into O'Hare and have a flight to miss and they say, oh, there's an engine delay, they'll be able to do it faster, better and cheaper than the competition. And that's, of course, what it's all about. Now, I tell you this because I want to ask you a question. When do you think this model of business was invented? Of course, we're not interactive here, so I'll show you the answer. In 2012, Rolls-Royce celebrated the 50th anniversary of this new business model. And that gave them something called Power By The Hour. And they are doing phenomenal in terms of what they're offering here. Let me just give you an example of how that works out. In a jet engine, they may have started out in the original mode of one sensor. This gives us the ability to do generalist maintenance forecasts. Yes, after X number of flights, hours, whatever it is, we need to do this maintenance on it. However, because Rolls-Royce has actually nine, excuse me, they have a million sensors that they get from all of these engines. And when they put a hundred sensors on this, it gives them the ability to do optimal monitoring targets. And engine will need maintenance when it appears this way or when the fan blades look at this way. By the way, I'm not an engineer in these, so that's to the extent of my knowledge of this area, but it gives us the ability to fine tune and still improve the safety records of these engines. And I've already told you, they've been doing it for 50 years and we do not have problems with jet engines. But they also were able to total up a billion and a half dollars in savings because they now no longer needed to have storage for fan blade parts and things like that, that they were able to do. They were able to look at these opportunity costs and come up with a completely different here. So I've gone a little bit long on this section here, but again, the idea is not sequencing your data strategy implementation. Quick side note on programming here, the January webinar will be of course focusing on data strategy as well. Our third category then is to failure to meet expectations. Many organizations simply start out with data and they assume that things are going to get better. Let's take a look at how that is typically done in most organizations. If you're going to implement business needs then many organizations will come along and say, what are those business needs? We'll just implement them directly and that'll be wonderful. I disagree and I say that is incorrect. The reason is because we're leaving an important variable out of here and that is what is the current level of maturity with respect to their data practices in the organization. If we don't understand what those existing capabilities are and make a match between business needs and our capabilities, we're going to hand somebody a very fast racing car. Or let's just take it a little better. Perhaps your family's had a great year this year and you're buying a new Tesla. I'm pretty sure that you're not going to give that brand new Tesla to a 16-year-old driver that has zero driving experience and expect good results. That's why we have beader cars. Well, I'm not going to say we need beader data systems, but we do have data systems that are well run in these organizations and when we have a match between the business need and the existing capabilities, it makes sense from there to roll out a roadmap and implement from that perspective. There's an additional capability here as well with respect to expectations. If I produce business value out of that strategic use of data, that means it's something that somebody can quantify and that's wonderful. But I've worked for a lot of organizations where that's the only thing they do and the organization itself is dependent on consultants. It's just as important to make sure that you understand you need to measure additional capabilities that you're creating in the organization. The roadmap has to be a combination of delivering some business value and some new capabilities to the organization. If you deliver only business value, you will not have the ability to sustain that effort once the consultants leave, once the urgency for that initiative is gone. However, if you deliver only new capabilities, management thinks you are a science experiment and that is not a good thing either. I work with groups all the time and I'm going to give you a sort of typical group that I work with, which may be five data management professionals each getting paid $100,000 a year. So one of the questions I'll ask them is okay, you've been working for a year. Do you feel that you have an obligation to show that you have demonstrated at least a half a million dollars in benefits? If you can't, if there truly is not that much benefit, then the organization is overpaying. Of course, the other question that we get is when will you be done whatever done needs on this. And I've had people say that's okay, my CIO gave me five years. They understand it's going to take a long time. That means that your bogey now has gone from about a million dollars for the one year to in this case, five years of two and a half million dollars, you're going to have to revise your benefits goal upwards. And that's a challenge because most organizations don't think in these terms. And there's one other little problem with this. I'm sure some of you have seen it already. Most CIOs do not last four years in their organization. So the chance is that this group is going to have a new boss who may have different priorities and want faster results not be willing to wait five years for things is a very likely scenario in this case. One additional piece on this, we've done a lot of work here in the Commonwealth of Virginia with getting people's expectations around these graduate students and also around nascent programs. So we have a very good program where we have our state agencies who are doing a wonderful job collecting data but don't necessarily have as much time on their hands to do the analysis and we're carrying them up with our students to school and giving everybody a really good experience all the way around for these. Again, we're talking about these seven deadly data sins. The fourth one here is not aligning your data program with your IT projects. And this is one of the more fundamental challenges that we have as data professionals because we have allowed the industry to build itself up in what we call an IT project or an application development perspective. Which on the surface seemed pretty good. In support of strategy organizations come up with a strategy and then they implement IT projects. Problem is that data is considered a added thing at the end and it would be the data within the scope of the IT projects. The problems is that this ensures, guarantees that the data will be formed largely around the applications and not around organization-wide information requirements. That the process architecture is narrowly formed around the applications and very little data reuse is possible. And you say to yourself, okay, that's a problem. By the way, our colleague Dave McComb has a wonderful book that describes this exact situation here. I've put it up on the chart there and you can certainly get your copy of that at Amazon if you need to. Here's the switch, though. I only need to take the data and the information and move it up a level and the IT projects down a level. Of course what that means is that they complete transformation of the way your organization does business. In support of strategy, the organization instead of starting on IT projects should develop specific shared data-based goals. Not database, data-based goals and objectives. And these would drive the development of specific IT projects with an idea towards organization-wide usage. The data and information assets are developed from this organizational perspective. The systems support the organizational data needs and complement the existing process flows and finally we get maximum data reuse possible on this. Again, topic on this is the book. You can get that for a 20% off today because of our publisher's piece on this. Let's take a look at how this works in context here. Many people think that data strategy is a document that you need to write and follow for the next 10 years. Anybody that believes that still after the year that we've all just been through collectively, I think needs a revision in their thinking. But the data strategy nevertheless should be saying specifically what do the data assets do to support strategy? How is data used to achieve the organization's strategic objectives? And the feedback out of the governance area is how well is the data strategy working? All of these, of course, are subordinate to and responsive to the organizational strategy. There is no other purpose in having a data strategy than to help support the organizational strategy. And the questions become how well is it going? We also put on IT projects and say how well is the data delivered by them and organizational capabilities with some feedback loops in there, et cetera, et cetera. No problem with all of this, but I do want to make one additional point on this chart, which is to say that I don't like to show that much information to most people. So I really like to make it a simpler piece. And the point I want to emphasize here is the data strategy must specify specific business goals as part of the data strategy. If you're not going to say I'm going to change some data things and therefore something good is going to happen to the organization, eventually somebody may ask who cares? And that's a reasonable question. Similarly, the language of data governance must be grounded in metadata. If we don't have the ability to talk in these terms, we will have more and more challenges as we get there. So again, the data program must be aligned with IT projects. Take it a little further here again. We've got the IT projects. Number three, you need a robust programmatic means of sharing your data. Data is not a project. Data is a durable asset. You do not manage durable assets with a project. Durable assets are assets that have a useful life of more than one year. And more importantly, you expect to invest in them to increase your return for the overall organization. So while it's reasonable to have project deliverables in 90 days or if you're into agile and two-week turnarounds, our data evolution is measured in years. And that's a very disappointing thing to a lot of people because it's a hard sell. What I tell people in organizations is if you're going to do this, it's kind of like joining a 12-step program. Yes, it is that fundamental and that important to be able to take it on. Data, remember, evolves. It is not created typically in most organizations. And consequently, it is more stable of an asset in most organizations, which means that ready-made data architectural components are a prerequisite to successful agile development. If you're in the middle of an agile sprint and you find out that your data requirements are wrong, you need to stop coding and go on to code something else. Don't worry, there's plenty to do, but these data requirements are going to need another look. The only alternative to that is to create additional data silos. I'm going to put a little joke here on agile. This could be just to be a little bit tongue in cheek on this, but here's a joke that talks about agile surgeries. And we might start out here and say, this is agile surgery. And the patient says, wait, you're going to perform surgery without putting me under. Yeah, this is agile surgery. We need to ask you about your symptoms and complaints after we open you up. Doesn't sound like the best way to do it. Oh, and by the way, we'll also need to know what you want us to work on in this first round. Now, let me show you why this is so hard for us to do as a fundamental piece. This goes back to a colleague that I was working with in the 80s. His name was Winston Royce and he was one of the more famous, foremost, software engineers that was out there. So I'm going to give you the explanation that he gave to all of the students when he was lecturing to them. And I think I've captured it in this slide here. What he said is that the way we do requirements for systems is that we work on those requirements until we get to the point of diminishing returns. When we get to diminishing returns, meaning we're getting less out of it than we're putting into it, kind of like looking at the same paper too much or the same PowerPoint deck too many times. All of these things end up in the same thing. We go out and we find a designer and we hand these requirements knowing that they are incorrect and imperfect and immature at this stage. And we ask the designer to design from these requirements. And most of the time the designer works on it for a couple of weeks and comes back and throws it in our faces and says, y'all haven't got the requirements right yet. Here are where I see there are a number of problems that you need to fix before I can properly design your system. And we say thank you because that's a great piece. It's another perspective. It gives us an opportunity to get away from them for just a little bit and we go back and redo them. And when we're done we find another designer. Now we're going to have to find a different designer than the first designer that we had. So this would be designer number two who we don't tell and they look at this and they say, it's not perfect but it's not awful. They may throw it back a third time and only after you've done this cycle three times do you end up with a set of designs that are useful enough to be taken forward. When we do that and take it forward we hand it to somebody to code and say, hey, we need to do some implementation in here, right? And again if you anticipate this the same thing happened that happened with our requirements in design loop we go back and do some more design. They come back and do some more implementation. Again, we may do some more design and this is a natural and should be counted on process. In fact sometimes when we hit that design stage we may find out we need to go all the way back to requirements and change the requirements. Therefore implementing another design and yet again still another implementation piece. Now all of this is critically important and if you don't understand the iteration that has to occur between requirements and design and then design and implementation and plan for it it's no wonder that these things don't work because what we did when we took it to college and university we simplified the process to make it easier for students to understand and I'll show you how problematic that is. But before we do that let's talk a little bit about how we spend money in this kind of an environment. Again, if we were here and I was in person I would ask you all to say what percentage of funds do you think we spend above the blue line and of course you can see the answer is 20% and 80% of our IT costs going down on the fixing and correcting things part of the occasion. So the fact that we're still doing this 80-20 split 50 years after being involved in this process shows that we're still not very good at this process above the blue line. In fact, there's good incentive to do this. This is another study that we did early on where we found out that if it cost a penny to fix something during the requirement cycle that I was describing there and we didn't catch that error until we went to the design phase that process would now cost us 50%, excuse me 50 cents or in other words 50 times more during design than it does to fix it during requirements. If we don't catch it until we've gotten to implementation that's the coding part here then it's going to be 100 times more difficult to fix than it would if we caught it in requirements. Unit testing again you can see the numbers go up we're up to about $5 at acceptance testing as fall into our verification box that we have and if we don't catch the problem until it's maintenance it's going to cost us 2,000 times to fix an error in maintenance than it is to fix it in requirements and that is an amazing statistic. All of these of course are still true and you'll notice them on the picture here I say 50% of the problems are only detected after completion of the acceptance test. So in spite of the fact that we are testing and trying to do as much as we can we're still only catching half the problems. That's why we spend 20% of our dollars on requirements, design and implementation and 80% of our dollars on maintenance in IT and I mentioned before but we don't even tell students how this works I just gave you I hope a very nice description of the back and forth that needs to occur between requirements, engineers, designers and implementation people and yet this is what we tell students you do this it's just crazy. We start out here we say you do requirements design, implementation verification and then maintenance as if they were sequential operations well the problem with that is that this allows us to develop and implement software and data within the same life cycle and it is wrong now I say it's wrong the only way this can work with this life cycle that we teach students is if there is no sharing of data that occurs outside of this particular project of course how often do you make a project that doesn't share data the answer is practically no. So let's take a look at that projects are data silos that's why we end up with so many data silos so we have project one and if it's supposed to exchange data with project two there's nobody in project one that's going to give any of their budget to fix that implementation there's nobody in project two that's going to get it so the integration becomes project three and you can see that this gives us to an n times n minus one over confusion it's a big big challenge around all these things so we aren't even teaching students correctly how to do this how can we expect organizations to do this it is a absolutely terrible situation let's finish up on this particular section here by giving one more point that says it's shared data structures require programmatic development and evaluation now when I say programmatic I'm hoping that most of you understand the difference between a program and a project some of you undoubtedly are PMP certified and that's wonderful the project management institute does a great job of making sure that people understand the differences between these two pieces one of the most important differences between projects and programs is that a project has a start and an end and of course data as we've already seen tends to be a longer lasting proposition and consequently does not fall into that start and stop pattern in fact when I talk to organizations I say that your data program must last at least as long as your human resources your HR program if you do not make that data program existing at the same level as your HR program you will never be able to do data well now let's just make sure that we understand what this means nobody in your organization goes around and says you know what I think we've hired our last employee I think we've got the last bit of bad behavior occur in our organization or whatever nobody asks are we done with HR and yet people are always asking those questions about data cement it in their mind how your management you will no longer need your data program when you no longer need your HR program managers do understand this by the way another reason that I use HR for this is my colleague Don was telling me a little bit about the history of HR and it turns out until about 70 years ago HR was a distributed read siloed organization in most places and only in the last 70 years has HR gotten its act together and said you know what instead of having it be done locally we should implement these standards throughout the entire organization so that you will have less need of lawyers and better quality human resources that you have in the organization so again hopefully that makes sense to everybody make sure that you absolutely have it in there because if you implement your means of sharing data without having a programmatic approach to it you will never be successful in the data world that is the third deadly data sin finally we're getting to the last two here we need to have qualified data leadership and yet imagine this now situation here where it's in this case federal government and the federal government is actually doing some things these days they are ahead of much of what's going on in privacy industry primarily due to the passage of a law we won't get into that I think this particular one but we can get into that at some point data as a subject is very complex and detailed it's poorly understood and it's taught incredibly inconsistency organization to organization and as a result we end up with our knowledge workers and our knowledge workers by the way definition of a knowledge worker is somebody who works with data right and we keep them in general nothing about how to do this and in fact the percentage of them that need to deal with it daily is 100% of them this is a crazy situation you are absolutely going to see organization start to screen their knowledge worker hires for data literacy if you have two candidates who are both equally qualified in all other ways you should hire the one that is more data literate than not and you may say to yourself wait a minute why does a knowledge worker need to have something to do with data well the answer is pretty simple I've worked with a lot of group just to give you one quick example of a group that had a hundred PhDs in chemistry and of course they are working with data because they are doing molecular compounds and modeling things that require all sorts of this but they would have no idea that the data system that they were using was never made to be Y2K compatible consequently they have all sorts of challenges that were there it's just not something most people think about and it's something we need to start thinking about we are still though we are teaching IT people incorrectly and one of the worst ways of describing that is that most IT courses get a single course in data which is how to build a new database if there is a skill we do not need anymore of on planet earth it is how to build a new database we've been teaching it for 50 years everybody knows how to do it but most importantly when we say that we have an IT curriculum that maybe has 10 specialty courses to give yourself a bachelor of science in information systems or computer science or something along those lines and other people go through these same programs they also get the sense that data is a technical skill that is not needed at management level it is only needed when I develop a new database so if I happen to be working in a situation where I am building a brand new ERP they say I don't need data people in the ERP implementation because I am not building a new database or if I am merging two databases together I don't need data people there because I am not building a new database do you see the problem here if the only skill they know how to use is how to build a new database then management will find opportunities to minimize the number of times they need to have data people around by simply not getting data by the way the other problematic aspect of this goes back to Maslow as well which is of course if we teach them that the only thing you need to have in data is the ability to build a new database why that's if the only tool you know how to use is a hammer you tend to see every problem as a nail is it any wonder there are so many siloed disparate unconnected databases out there in the world and now we need to go back and start fixing them and that is a non-trivial process but the question however imagine your hiring panels that are involved in this particularly for positions in leadership it's just not possible for people who don't understand data to determine whether somebody else that they're trying to hire has data skills and by the way it's not just data skills I've already showed you it's leadership skills in there as well so hiring panels at least within the federal government are now starting to be shared across the various agencies it's unlikely that two banks are going to compete and also try to get two data people in there but there needs to be something done to make sure that these hiring panels can in fact do the job that we're asking them to do see we need to have somebody at the top managing the data if we do not have somebody at the top managing it becomes everybody's responsibility and I ask organizations how is that working out for you since that's what you currently got the top job we like to call it the top data job some people like to call it enterprise data executive of course CDO sounds really cool but I've already told you there's challenges with those titles I don't care what the title is but we need somebody in order to be in charge or if you will one throat choke that individual is going to be responsible for liaisoning with the top IT people and working in a data governance organization and there's three things that the top data job should be focused on one 100% focused on data asset leveraging two unconstrained by an IT project mindset and three reporting should be into the business not into a project organization in many cases your first data leader is going to get killed I don't mean that badly but there are two different skill sets in there one needs to come in and do some change and another one needs to basically make it work in the way of an operative capacity doesn't mean your first one always will be but we're seeing fairly short timeframes between one and three years in most areas so let's get to the number one problem with data sense and that is that most organizations do not understand what we mean by saying data centric thinking now let's first of all understand that data is a source of hidden IT expenses I guarantee you that your organization is spending between 20 and 40% of their IT budget evolving data this includes migrating your data converting it from one form to another or improving it in ways that we'd like to do it and I can tell you that Walmart when I was there was spending four billion dollars a year on IT so 20% of that turned out to be quite a lot of money I've put out there a bit called the data doctrine you can go to the website thedatadoctrine.com and see these out there and if you're interested in following up on this discussion just add your name to the list and I'll make sure that you're on the mailings that we do on this but we put in place four different pieces here and this hopefully looks a lot like the agile manifesto as well so it says while we're trying to uncover better ways of developing IT systems by doing it and helping others do it through this work we have come to value and again I've put in four specific statements and underneath those four statements it says while there is value to the items on the right we value the items on the left more so let's dive into each of these things here's an IT program driving a data program and these things are just completely different we've been trying to get them to work together for a long time but we are simply not able to do this I've already mentioned that IT is a faster discipline where we can create things and understand how to build things in an agile fashion and agile is the best way we have managed to come up with a faster way of producing higher quality software but agile does not work for data because data evolves over time and our current state to our future state it takes several years to do this if we try to do it simultaneously with our IT efforts it does not work data evolution must be separated from must be external to and must precede all of the rest of the systems development activities it needs to be separated and see for us second tenant of the data doctrine says that we prefer informed innovation investing driving the various technologies in this case and what we mean here is to take a look at a particular data system that we have here's an older system that I have and I'm going to put up some business rules on this first one has to do with moon lighting and the second one has to do with job sharing so what I've done here for this data model is that a person or one employees that's a very rigid data structure and that means that if some organization permits moon lighting getting another job with the organization working over time on this this system will not work in order to do that a system that will work can be described by simply adding in here a couple of one to many relationships instead of one to one relationships and permitting this small data change allows us now to support business rules that include a person can have an employee on Monday and another person can be a different employee on a different day or a different time of the day similarly for the job sharing one you may have a job that exists for everybody working before lunch and somebody else coming in and taking the job after lunch without those two changes the system will not do that and more importantly if I put those two very simple data structures that I described the one on the left is more flexible and the one on the right is less flexible you can see that the one on the right is going to require more structural loops in other words if you were coding this thing and then we change the data structure on you you would have to go back and completely restructure your program these data structures must be specified prior to any software development or acquisition if you're buying a software package also request a vendor to provide you with a data model so that you can look at it our first data tenant is shared data must be driving the IT component evaluation in here people don't generally understand what's going on with data I've mentioned that a couple times here and that's why I'm showing it as a little great triangle in the upper left-hand corner but if you do this well and improve the way you're doing it your data results will become more and more concrete less opaque and over time the number of requests will increase the utility will increase and data's contribution will be recognized in there again data cannot exist without this programmatic stuff and finally data reuse is our fourth tenant here this is to say that if I have somebody who's looking around this gray database as a DBA they may be able to enforce standards that span program A, B and C but if that individual doesn't have span and control over to the orange or the green databases you're likely to end up with messes on the inside and who's making those decisions well without leadership nobody is making changes so to make a change in the program there may be nine maximum changes that we need to make but if I'm going to change the data that's around here the worst case scenario is that n times n minus 1 over 2 possibly 36 changes that need to be made in this area in order to do this so again understanding what we mean in concrete terms by the data doctrine in this case what data centric thinking means you need to have objective behavior so somebody can look at them from an objective perspective and say hey this makes a difference or it doesn't make a difference so we're almost at the top of the hour let's just briefly go through them again seven deadly sins first one is not understanding data centric thinking it is possible to do this not attaining qualified data leadership not implementing robust programmatic means of sharing data not aligning your data program with your IT projects failing to manage expectations not sequencing your data strategically and finally failing to manage the culture and change management aspects of the various challenges because most organizations have this perception that data is sort of this little bat sign that sits there between business and IT and it turns out it's a little bit bigger and if you play with it a lot you'll realize it actually looks like this in order to take on with the entire world so we've got some upcoming events again in January we're going to do the data strategy one we'll do some best practices in February and start to look at some governance issues in March I didn't mention these two books but these are two books that are very important to take a look at one called the big nine from Amy she's done a great job of describing why the AI efforts in most organizations are doomed to failure and this one providing something in the way of surveillance capitalism on this where Shoshana Zuboff has done just a great job for this so these are wonderful Christmas reading books or if you have a data person on your list certainly either one of those will be welcome of course we'd always love it if you would pick up some of our books here as well and I did mention that I've got that let me get to that page so you can see it there we go so we've got a couple books on sale today you can go right to the website plus anything awesome calm and get extra stuff off on these because after all if you don't have that hard to get the rest and we're right at the top of the hour and ready to go back Paul for some questions and answers one very informative presentation if you have any questions please take a moment now to submit them in the Q&A box also to answer the most commonly asked questions as always we will send a follow-up email to all registrants within two business days containing links to the slides and yes we are recording and will likewise send a link to the recording of this session so Peter the first question we have here for someone who wishes to identify the current state of their organization are there any resources such as website books etc that you will put in the concept surrounding data maturity assessments okay I hate to look at like I'm promoting my book but I'm pretty sure that in the data strategy book I have a little bit in there on the assessment process that said it's not that difficult to look at what you're doing so let me flip us back to one of our organizing platforms in here which is the DIMBOK on this and really you can look at any of these areas so I've circled again metadata management and to say are you going to implement this in a regular format or are you trying to do it in a way that actually works so let me give you the basics of the assessment process here the assessment process is a five-point scale if you google VMM and the name Melanie Mecca you will find my colleagues on the page out there that she's done a great job she's the author of this wonderful work the scale turns out to be one to five at one you have a pulse that's a pretty low standard for doing any of this at two though you're now saying that your data management practices in this area are repeatable if you have three you're now saying you have some documentation that exists about how to do this if you're at level four you now measure things in your data management processes and level five you actually start to use the data that you collect through measurement and observation and improve what you're doing so I've circled the metadata management the focus would be to look at metadata management and say hey are we having a pulse yes we have a pulse so that gives us one point is our metadata management practice repeatable if it isn't you get a one for that if it is repeatable the next question that you would ask then is is it documented because after all if Peter is doing all your work for you and Peter hits the lottery Peter may not show back up to work the next day right I'm being a little bit silly on this but it's okay and then we get to four is Peter taking measurements of these things so does Peter written anything down to come up with level three are there measurements that are occurring around and one does metadata management and finally are we using this data to improve the metadata management aspect of the projects or other aspects of the projects so this assessment can be done I don't want to say pretty easily but it's not hard and many organizations will charge you money to come in and do this do be careful too I've run into many customers where they say I did the CMM thing because my consultant told me that's what I was doing but I look at it and I see what they've done and it's not but don't let people sell you bill of goods in this area make sure that if you're going to do this you're doing it through the correct process and you don't need to be comprehensive about it if you're only working in a few of these pie wedges as we call them then work on those pieces there's no point in getting really good at document and content management if you're not managing any documents or any content and hopefully that makes sense so great question thank you Paul and thanks for that Excellent and Peter we're getting a few slide with the discount code if you could just get that up on the screen that would be helpful for sure and of course you all get copies of this when we're done so it's not too hard to get a hold of these but absolutely make great stocking stuffers for these things absolutely and Peter we have for one of our attendees they'd like to know what are some popular examples that you would consider for motivating data across stakeholder channels everybody's asking me questions for which I have graphics in other presentations for so let's let's try and imagine this if you will actually let's not let me let me go to a slide here so I'll go back to this one which is to say whoops there we go so if I put this slide back up here when organizations are trying to do these initiatives whether they're building a data lake or data warehouse or whatever it is using a chart like this can show the organization that they shouldn't put the data in the data warehouse and then clean it I mean I hope that makes sense to everybody because that same data is likely going into your machine learning process or your master data management initiative or you're trying to run some AI off of it so we've got to go back and get to the more fundamental places where this actually does make a difference in there probably you repeat the question I want to make sure I answer it fully I think that's what they were asking for but yeah absolutely for this specific learner they were just interested in learning some popular examples that you would consider for motivating data across stakeholder channels within an organization so that goes back to our monetizing topic and you'll see this again as a topic that a lot of people are working on again one of the books at the end there is focused on that topic but what it does is it says look if I'm going to buy a fancy new technology anything that's in the middle column or even stuff things that I haven't put in the middle column of this diagram bad data is going to be a problem and so you may have your entire blockchain initiative crash because you have extremely poor data that you've put into your blockchain initiative by the way are we over that yet and we figured out what the good uses of blockchain are and are not I saw somebody trying to run a payroll application off one of those the other day and it gets to be pretty silly sometimes around that but the key is to show that an investment in data at this level will result in multiple types of payoffs as the data flows through your organization and that's really the key and I'm going to get on a high horse here as well because it's usually the second question that pops up around this which has to do with data ownership now if there is a thing that should never be owned by an individual in any organization it is the data imagine for a minute you're the accounting group within your organization what data do you own and the answer is none your data comes into you from other parts of the organization nothing wrong with that but ownership is the wrong concept so by letting somebody own a pile of data you are putting in place a situation where they're going to say it's mine and you can't do something with it whereas the proper way to do it is that you are a fiduciary for a certain subset of the organizational data and the organization has entrusted you with this subset of the data and that your purview is on making sure that that data is accessible and available to everybody else who needs it so if you create it and do it in just a single little block piece I'll go to the place where this started on this if I've got some garbage data and I've got this great model and I'm getting garbage results and I fix it here that's wonderful but that same fix to that garbage data would probably have also helped out with several other types of initiatives that are going on there and once people understand the connectedness around data it becomes easy to add up the costs of all things going wrong I'm working with a company right now that is dealing with some really interesting issues where they're trying to figure out whether something has been made in a certain country and it turns out that each country has a different definition for that type of make so the company is clearly going to have to adopt a company standard because there is no existing set of country standards or made in and they'll be able to work that out there anyway great question I think the key to it is to just find out if you could show somebody how a little data problem over here causes a problem there and then there and then somewhere else I'm not showing anything on the screen here but again in different places that's your best way to let people understand how this kind of an investment can be so productive again great question thank you and what is the best way to determine data literacy so I'm afraid you're going to have to wait for my book on that but I can at least talk a little bit about it data literacy should occur in five levels in our society these pertain to five objective criteria that we have the first the lowest level of data literacy is somebody who is what we call a mobile data spreader that is somebody who is not an adult and who has a mobile device of some sort that is connected to the internet again remember in these days we're talking about a super computer connected to the internet so yes I'm saying basic data literacy should occur before somebody is granted the privilege of surfing the internet with a mobile device of one sort iPad iPad all the Nintendo boxes the new PlayStation all of these things are going to fall into that particular category that's the first level of data literacy and we can't control that because they're kids right we don't have a law that says you must be data littered as a kid but we do have parents and hopefully the parents will figure out that it's a good idea to have some conversations with everybody on that the second level obviously is a mobile data spreader who is an adult now when you become an adult in society you actually are granted additional rights and privileges and given additional responsibilities all of those are very important that as an adult you should have some specific level and I've got in this case a set of citizen data literacy needs that I've articulated in the book there are I think nine at the first level another seven at the adult level the third level up from that is your knowledge worker and your knowledge worker should absolutely be data literate as I've already described in here and that those specifics of data literacy are in the book I wish I could give you more on them but the book will be out real soon Todd and I are almost done with it so we're really excited hopefully it will be something fun for you guys that's the third level of data literacy the fourth one then is that if you're going to teach this stuff you really do have to have additional certification around this I'm sorry but I've seen too many people attempting to teach this and teach it just simply wrong and that has not helped if you're going to go to college and university and you're being taught by somebody who doesn't know what they're doing how are you going to know that and the answer is most people don't and consequently you're going to have colleges and universities to deliver subpar data education for three decades without investing in them the last level of data literacy then is if you're going to call yourself a data professional I don't mean a data scientist I mean the lowest level you're maybe a report writer or something there is a basic level of data literacy that you should have around those issues you can see what's going to happen here Paul if I get too much longer we'll get into the next next year's literacy on this there are some things out there if you're interested I'll be glad to talk to you offline in fact may I be in the position a couple of weeks to look for some reviewers who want to take a look at that great question thank you for asking that one what are the two criteria for balancing centralized and distributed control and execution of data management processes fantastic question so they're going to depend just like everything else on the organization and from a data governance perspective as well on the organization we cannot say there is one way we should do this because your organization is different from everybody else's so just as your data governance effort should be customized to your specific needs in here so too should your your idea between what should be centralized and what should be federated if you will have to occur let's make a decision you have to study that decision a lot of organizations are looking at very carefully whether they have to pay attention for example to privacy regulations and the typical approach from a privacy perspective is let's make sure we're GDPR compliant because if the U.S. isn't there yet it'll probably get there pretty soon and we're already seeing this with the California Act and the Federal Evidence Based Policy Act we're both starting to drive responsibility for data going in those various directions around that. It's a tough one it'll be a little bit more around that but if you don't have the data to determine how many decisions are made and how often they have to occur I was working with a CDO for one of the states a couple weeks ago and he told me a specific story that he said his oversight committee wanted to get involved in any decision where they spent more than $50,000 and so he went back to them and said hey that's great I'm glad I'd like to have the help by the way do you guys realize that we have evaluated more than 170 contracts where the $50,000 cap has been exceeded and that means that we're going to have to have a lot more of these meetings that we're going to have are you guys prepared to step up for those meetings it was a really nice you know again we only spent 10 minutes on each one of them so it's going to require us to meet for a longer time than most people anticipate so until you have the data that tells you what should be federated what should be centralized it's very difficult to make any pronouncements about that a priority but get the data and then we can start to look at these things all right and Peter can you please share some experiences on how best the data teams with agile DevOps teams and ongoing systematic structure it's a tough one so again what we're looking at here is the old way of doing things which is to say that we had simply a very reasonable process let's have some strategy and let's apply some IT to that strategy and see if we can get good at it but if you want to be data centric data can't be the third thing that we do in there so the question of how does this work from an agile perspective is really a couple of slides and I'm just going to pop them up here first transformation obviously is this one data has to go before IT projects if it does not it's a problem I'll share next month when we do the data strategy talk that a data strategy cannot be subordinate to IT strategy and work because IT strategy brings things down to a project level and if you're at the project level there's no way that you can do this is what we've been doing is like the way it is tell me to shut up and you you're very very happy with all these things so given that kind of a context in there people don't really realize that data is not a project it's a program and the sooner that you can tie in your executive's mind I know I'm repeating myself here that your data program must last at least as long as your HR program and it needs to be funded at a similar level in order to do this there's we will make a success on that. So again, it's the idea that there's a lot of things that we could be doing out there, but we've been teaching people how to do them wrong, which is not a service you should pay universities to deliver to young, impressionable people or others that are going on for masters and postgraduate degrees around them. See if I can come up with one more story around that as well. I'm not sure I've got one right off the top of my head. Yeah, that's good. The next question. Thank you. That's good. Good question. Based on your presentation, Peter, it looks like we're all sinners. So for this one attendee, they'd like to know which sin should they focus on first? That's the question. And yes, unfortunately, we are all sinners, which is why we came to the name that we did for this. It's something that you can actually put out there and people will understand. So which one to attack first? Well, I guess I'm going to give a qualified answer on that. If your organization is facing a burning bridge issue, and the burning bridge issue is something bad happened, and now we need to fix it. Maybe somebody got fired or something else happened around that. If you're doing that, I would very much absolutely look first at sin number four, the IT program and the data program need to be resynchronized in a proper fashion on that. If you don't have a burning bridge, though, if there's no crisis, if you've just just, oh, let me say something else here. In the book, I put in that doing one of these data-centric journeys is very much akin to starting a 12-step program. Now, that's not necessarily an analogy that people like to have, but if you've known anybody who's participated or tried to participate in a 12-step program, you know that it's a very big step. And that very big step is the same kind of thing that we need organizations to step up to too. So I use these things like data sins and 12-step program because management does understand them. And I say, you know, are you willing to commit to a 12-step program to improve your data? And they say, what is it involved? And I said, well, the first step of the 12 steps is admitting you have a problem, right? And if people that want to admit they have a problem, they're probably not going to be able to do much success in this area. That said, if you don't have a burning bush issue, I would start off with sin number one and try to figure out more about data-centric thinking and what it means to your organization. Again, great question. Thank you for that. And so most of your presentation appears that it requires C-suite direct engagement and understanding. So how do you get out of the project cycle without active C-suite? Yeah, so there's a couple ways. You can hire a consultant to come in and yell at management and say, you know, hey, you guys are doing this wrong and everybody else is doing it. Now, luckily we seem to be over that curve. Gartner's showing us that there are more than 5,000 chief data officers that exist in the world right now, which means some people are getting experienced about existing at this top level. And let's take that a little bit further too. If you've got a top-level person, do you think they should be really good with AI algorithms? Probably not. That's not where the conversations are going to go because if this top data job is trying to talk to the top finance job about artificial intelligence, it's not going to connect very well. But if they're talking to them about business problem, about closing the books a little faster, oh, there's an example. I can give you a good one now. This is going back to the last question. Sorry, Paul, a little scattered on this. One organization that I was working with hopefully had a 30-day delay in getting their bills out. So they would do the service in the month of October. In the month of November, they would produce the bill and they would ask for money in December. Most of you can see that there's a way of improving that. They didn't really, they thought they had to correct all their data by changing the data rather than fixing the problems. They wanted to treat the symptoms rather than the problems. But when I went to their chief financial officer and said, would you like to improve your cash flow on $9 billion annually by 30 days, the CFO looked at me correctly and said, she said to me, well, look, Peter, if you can do that for less than $800 million in less than 30 days, you've got yourself a winning project on your hands. And I said, oh, it's not a project and no, we can't fix anything in 30 days. But absolutely, we can definitely get you out of this process treating your symptoms continuously. So your top data job really has to understand what it means to interact with the other C levels. They have concerns that are not necessarily related to the things that you care about, but they are a case where we want data things to make a business thing happen. And if we can show the rest of the level at this, the rest of the C suite at this level, that if we make these data things happen, and therefore these business things happen, they will then argue for more resources to go into the data program because we're telling them that we can fix some of the business things that are happening by improving the data in there. Again, great question. I appreciate that. Thank you. And do you have any ideas where companies have successfully implemented data strategy? Quite a number of them. Of course, the book has one in it as well. When we do the data strategy thing next week, sorry, next month, we can talk a little bit more about that, but let me just do a little bit on data strategy here too. So many people approach data strategy by focusing on the product, the actual strategy itself. Now, if any of you out there have ever seen anybody read more than 10 pages of a data strategy, I'd like to know about it because I don't see it. I've looked at data strategies from organizations from the very biggest to the very smallest, and the strategy itself is okay. But it's kind of like trying to write the world's greatest pop song on the very first try. It doesn't work out so well. Instead, what you have to do with strategy is to start practicing. And what that means is that your strategy should be something that is cyclical, something that you can take measurements of, that you can record documentation of, that you can make into a repeatable process, and that you can analyze that data later on to say, how should we change our perspectives around that? So from a data strategy perspective, there's lots of organizations that create these data strategies and then try to follow them. Well, how many of you had a strategy document last fall and then COVID hit? Right? It almost throws a monkey into the monkey wrench into the works. So data strategy is much more about learning to build capabilities in your organization than it is about how to write a document that's going to read well. So I really de-emphasize the work product and instead emphasize the capabilities aspects of strategy. You'll hear more on that next month. And if data projects do not work with agile, what is the recommended approach for methodology? Well, the real key there is to say that agile, again, is the best improvement that we have managed to come up with in creating better quality software faster. No question about it. It does a great job. On the other hand, if you try to say that project in agile will also define within that two weeks or 90-day increments come up with the data requirements of it, it just can't happen. So the only alternative in an agile fashion is to create more silos of data. And of course, we just simply do not need them. We're working on all sorts of different aspects with this. But the key is not to say that data is not a project and should not be managed in any way, shape or form and with project management discipline. It's not to say that a part of a data project can be, but it is a program. And that's really the key there is to make sure that people understand that this is going to last as long as your HR department is going to last in your organization and that these programs are going to give you certain gateways that say now that we have the data requirements well understood and validated, it makes sense to invest in developing some software or buying software. Remember, this applies to both make your own and purchase software. It is a best practice to ask for a copy of the data model before you buy it. And if they won't give it to you, don't buy it. And Peter still staying with the concept of agile, the idea that agile as a theory homogates where teams should consider user needs of the mobile and to adapt quickly to a changing context of the information as opposed to arbitrarily planning too far ahead. Would you agree with this approach? Absolutely. And I'll put it up here again. This is the agile doctrine, we are uncovering better ways of developing IT systems by doing it and helping others do it through this work. We have come to value and they put in four different statements that I did in there. But those four statements that they have on the agile manifesto are brilliant. They did a good job of figuring out how they could do this. What you have to understand is that you can't go change your data just like that. You do not do a lift and shift. It doesn't work. Data, again, it evolves over time and the progress is measured in years. And that's one of the things that's important when you're trying to sell this to the C-suite. If your chief executive is likely to bug out of there next year because they think they're going to get a better job because they've done a really good job for your organization, they are not going to be willing to invest in a data-centric exercise. And there's no point in trying. And let's just say what it is. This person doesn't have the attention to focus on it and it's not right for us right at the moment. It's going to require a minimum of a five-year commitment in order to do this and to do a good job on it. It doesn't mean you can't get results faster than that, but the initiative is clearly going to have to be measured in half decades. Four minutes here before we conclude today's webinar. The next question, Peter, is for one of our attendees. They don't believe the details of what is the best way to determine if someone is data literate was answered, just that you need to choose a person who is data literate. So they're wondering if you have any examples of this that you can kind of speak to. Again, for each of the levels that I described earlier, there are specific outlined citizen data literacy needs. And I'll have that book ready for review, hopefully, right after the holidays on this. But let's just take a very simple example. If you're working with two individuals and you're trying to figure out which one of them is more data literate than the other one, a way that you could use to measure or at least get an insight into the literacy of an individual might be to say, can I look through your contacts and your mobile device? But that's a pretty rude conversation. Many people are like, but you can look through the contacts and see if they are managing data well or things look haphazard. Another thing, if they won't give you a contacts list, might be to look at their musical playlist. Many people just read their stuff into their musical player and they have to go find it every time. Whereas musical playlists have all sorts of wonderful things like smart lists. And, you know, you can sort things based on the number of times it's been played or whether something exists in the cloud or whether it's not or by a genre of music. The amount of organization that somebody puts around that is another indicator of how they could. Again, when the book is out, I'll have some very specific things that look to it, but I'm just not quite done with the book. And going back to one of the first slides, Peter, under metadata management, is the architecture supposed to be supported by ITs such as a manager and architect? And does it make it more complicated if an organization is moving to a new system in parallel to the aim to have data management? Absolutely. And that is why the data stuff should be done first because if you do not understand the data requirements for your organization, the software that you are looking to acquire or purchase or buy into or whatever it is that you're going to do may help or may hinder your organizational processes. Again, I'll give this example. We talked about it earlier, but it's still very relevant to our task. If we're looking at the two pieces of software that... The two pieces of software, one of them works like the one on the left and one of them works with the one on the right. Anybody looking at those data models can say, well, the one on the left will give us the ability to meet more requirements in the longer term. And they're quite clearly, they can see this. So before you buy software, absolutely ask for that software to be delivered to you a data model of what that software looks like so that you can do this kind of analysis and determine whether or not that software will complement your existing business practices or whether you're going to have to rework something to make it work with the new software. Again, a very specific example on this. I was working with one group that they had all of the data on one screen. It was really easy for them to use. And in the ERP that they were acquiring, that same data was spread across 23 other screens. Well, hopefully you see that we need to examine the process architecture around this as well as the data model in order to see what we can make complementary versus non-complimentary. All righty. Well, thank you once again, Peter, for the great presentation and Q&A. But I'm afraid that is all the time we have for today's webinar, Exercising the Seven Deadly Data Sends. Just to remind everyone, we will be posting the recorded webinar slides to dataversev.net within two business days. And I will send out a follow-up email with the links to the recorded Q&A slides. So thank you to everyone for attending today's webinar. And I hope you all enjoy the rest of your day and stay safe out there. Bye for now. Thank you, Paul. Happy holidays to everybody. See you all January.